На прошлой неделе мы провели вебинар, на котором я взял интервью у Адама Торнхилла, технического директора и соучредителя CodeScene, о техническом долге: что это такое, почему он важен и как им эффективно управлять.

Для этой статьи я выбрал одни из самых интересных вопросов, которые мы получили от аудитории. Если вам интересно узнать больше — посмотрите полную версию вебинара.

Алекс: Я Алекс, соучредитель и генеральный директор Stepsize. Я провожу все свое время, говоря о техническом долге с членами команды инженеров, и я искренне рад, что сегодня со мной Адам, технический директор и основатель CodeScene.

Адам написал книги, такие как «Ваш код как место преступления» и «Рентгеновский снимок дизайна программного обеспечения: исправление технического долга с помощью поведенческого анализа кода», в которых Я бы отнес к классике по теме технического долга. Мы очень долго следили за вашей работой — и теперь у нас есть возможность задать вам вопросы.

Расскажите немного о своем путешествии — как вы заинтересовались техническим долгом и так глубоко в него погрузились?

Адам: Это путешествие началось еще в моей прошлой жизни, когда я был консультантом по программному обеспечению. В рамках этой роли меня часто нанимали в качестве технического руководителя или архитектора программного обеспечения, и одна из моих обязанностей заключалась в том, чтобы убедиться, что мы можем предоставить продукт как можно быстрее и с наилучшим качеством. Я часто находил это невероятно трудным, потому что мне приходилось сообщать своим бизнес-менеджерам и владельцам продуктов, что сейчас самое время сделать шаг назад и погасить технический долг.

Это были тяжелые разговоры, и я пробовал разные подходы, например, рассматривал разные показатели сложности и инструменты анализа. Но было трудно воплотить мой технический взгляд во что-то значимое для моих менеджеров.

Пока я боролся с этим, я также занимался психологией, изучая судебную психологию. У меня была идея, что если бы я мог отслеживать движения разработчиков в базе кода, я мог бы использовать это, чтобы выяснить, какие части этого кода влияют на большинство людей.

Именно с этого я начал 10 лет назад и провел последнее десятилетие, работая над этими идеями.

Алекс: Прежде чем мы углубимся во все, что вы узнали за эти 10 лет, не могли бы вы рассказать нам, почему вы считаете, что технический долг является такой важной темой сегодня?

Адам: Это может быть клише, но сегодня каждая компания становится компанией-разработчиком программного обеспечения. Я не понимал, что это значит, до тех пор, пока несколько лет назад я не работал с клиентом, который занимался металлоломом. Они полагались на тонну сложного программного обеспечения для своей логистики. В тот момент я действительно понял, как программное обеспечение влияет на каждый бизнес.

Следствием этого является предложение талантов: в мире ограниченное количество разработчиков, и даже если у нас есть бюджет, мы просто не можем нанять всех людей, которых хотели бы нанять.

Это означает, что мы должны работать с людьми, которые у нас уже есть, чтобы выполнить больше работы, и технический долг является важной частью этого.

Алекс: Как вы определяете технический долг?

Адам: Существует так много определений и разновидностей технического долга: стратегический, преднамеренный, безрассудный… Но с годами я пришел к выводу, что не так важно знать, откуда берется этот долг — важно его влияние.

Мое определение таково: технический долг — это любой код, который стоит дороже, чем должен быть, код, за который мы должны платить проценты.

Алекс: Мне это нравится. Мое рабочее определение: любой код, который вы считаете пассивным, именно по указанной вами причине.

Ранее вы упомянули, что вам приходится много вести переговоров с заинтересованными сторонами. Как инженеры могут помочь нетехническим заинтересованным сторонам понять технический долг и важность постоянной работы с ним?

Адам: У нас есть проблемы с общением между инженерами, выполняющими техническую работу, и заинтересованными сторонами, мы используем разный словарный запас и фокусируемся на разных вещах.

Когда я иду к своему нетехническому менеджеру, чтобы сказать, эй, слушайте, нам нужно реорганизовать эту вещь, потому что у нее цикломатическая сложность 500 — для них это ничего не значит, им все равно.

Что мы, разработчики, можем попробовать, так это использовать более бизнес-ориентированные показатели, такие как потерянное время или влияние на клиента. Мы можем сказать, смотрите, в прошлом месяце мы поставляли на 30% быстрее, и у нас было меньше ошибок — вещи, о которых заботится каждая компания-разработчик программного обеспечения.

Алекс: Абсолютно. Теперь давайте поговорим о приоритизации технического долга. Все ли технологические долги одинаково важны, а если нет, то как правильно расставить приоритеты?

Адам: Для меня не все технические долги одинаково важны. При определении приоритетов технического долга я обращаю внимание на 3 вещи:

  1. Воздействие: насколько этот конкретный долг влияет на нашу способность выполнять обязательства?
  2. Бизнес-приоритеты: как технический директор я уделяю большое внимание нашей дорожной карте продукта и хочу убедиться, что мы сможем ее выполнить. Если я посмотрю на свою дорожную карту, я сразу узнаю, какие области мы собираемся затронуть.
  3. Тенденции: мы становимся лучше или хуже в режиме реального времени? Тенденции имеют тенденцию быть действенными.

Алекс: Давайте поговорим о качестве кода. Есть много инструментов, которые помогают с различными аспектами технического долга. Чем CodeScene отличается от инструментов контроля качества кода? И какой стек идеально подходит для правильного управления техническим долгом?

Адам: Конечно. Я могу сделать попытку. Конечно, я буду немного предвзятым, но я постараюсь :)

Я всегда был большим поклонником инструментов статического анализа и до сих пор ими пользуюсь. Я думаю, что они полезны в качестве низкоуровневых циклов обратной связи во время разработки, они могут помочь выявить определенные ошибки, но эти инструменты никогда не предназначались для управления техническим долгом и определения его приоритетности.

Именно по этой причине я начал развивать эту область поведенческого анализа кода, которая помогает нам расставить приоритеты технического долга.

Пространство, интерес к которому сейчас растет, — это человеческая сторона кода. Для крупных организаций, насчитывающих более 100 человек, организационная сторона становится даже более важной, чем вопросы качества кода. Например:

  • Есть ли у нас подходящие люди в команде?
  • Есть ли части кода, которые мы больше не понимаем?
  • Насколько слажены наши нынешние команды?

Все это информация, которую вы можете получить из CodeScene.

Кроме того, у вас есть Stepsize, который помогает с более качественным анализом и добавляет контекст.

В какой-то момент вам понадобится каждый из этих инструментов для успешного управления техническим долгом.

Алекс: Я, конечно, согласен, из данных git можно получить так много информации, которую нельзя получить из обычных инструментов статического анализа.

Еще один часто задаваемый вопрос: кто несет ответственность за технический долг?

Адам: Простой ответ: все заинтересованные стороны несут ответственность за технический долг, но за разные его аспекты.

Я вижу некоторые компании, которые относятся к техническому долгу как к технической проблеме. Я просто не думаю, что это будет особенно успешным. Как разработчики, мы можем знать, как погасить технический долг, и мы можем даже знать, где он находится, но мы очень редко владеем своим временем. Обычно кто-то другой говорит нам, на чем сосредоточиться. Вот почему я считаю важным, чтобы деловая сторона брала на себя технический долг и устанавливала приоритеты.

Менеджеры и специалисты по продуктам должны помочь найти баланс между выпуском новых функций и обеспечением устойчивого развития с течением времени.

Алекс: Мне нравится применять процесс, описанный в статье Идеальный процесс управления техническим долгом. Инженеры несут ответственность за применение правила мальчика/девочки-скаута: оставьте код лучше, чем вы его нашли. Это обязанность каждого инженера. Затем, когда мы говорим о средних долгах, обычно у вас есть руководитель группы, который может пойти к менеджеру по продукту и поговорить о долге, который должен быть включен в этот спринт.

Затем менеджер по продукту должен решить, как распределить инженерные ресурсы между обслуживанием и функциями, которые у них есть в спринте.

Что касается больших долгов, то, что я обычно вижу, в зависимости от размера компании, это то, что у них есть Штат или главные инженеры, которые создают технические предложения для более крупных проектов. Кроме того, за принятие таких важных решений отвечает руководство по разработке и выпуску продукции.

Этот процесс помог многим компаниям гораздо эффективнее справляться с техническими проблемами, и мы надеемся, что он и этот разговор помогут многим другим командам.

Если у вас есть дополнительные вопросы или комментарии, напишите мне или Адаму в LinkedIn, и мы будем рады продолжить этот разговор.