Вы знаете, каково это. Впихнуть всё необходимое в спринт и так весьма непросто, а ведь ещё нужно где-то найти дополнительные 10–20% времени разработчиков на возврат технического долга. Если вы когда-либо отстаивали необходимость выкраивания времени на это, то вы знаете, что это походит на крестовый поход эпических масштабов.


Но сделать это можно, и в этом руководстве мы выясним, как именно.


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


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


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


Имеет смысл пытаться удерживать своих разработчиков, чтобы создать культуру знания, обмена и доверия. Но на это уйдут годы тяжелого труда, и, заканчивая рефакторинг, мы всё ещё почти не имеем понятия, не впустую ли мы потратили своё время. Мож��т быть, мы только что сэкономили несколько дней из будущего времени на разработку? Или же мы могли бы подождать еще чуть-чуть, чтобы погасить технический долг позже, и вместо этого добавить несколько новых фич? Мы никогда не знаем наверняка и списываем своё незнание на то, что разработка продукта — это скорее искусство, чем наука.


Что ж, самое время добавить в процесс немного науки.


Чем похожи надежность сайта и бюджет техдолга


Должным образом управляемый и целенаправленно планируемый технический долг может быть бесценным инструментом. Осознавая, что мы делаем, мы можем использовать его подобно тому, как используем финансовый долг, — в качестве плеча. Но если мы, сами того не подозревая, берем на себя слишком много — например, не понимаем до конца условий сделки (то есть влияния, которое техдолг оказывает на нашу кодовую базу, клиентов, команду и бизнес) — дело может кончиться крахом нашей компании.


Лучшие команды по управлению надежностью сайта оперируют своим бюджетом надежности сайта в понятиях управляемого технического долга. Надежность сайта (Site Reliability) — понятие, популяризованное Google; она отвечает за сохранение программных продуктов в состоянии «запущено и работает», но, что интересно, компании вроде Google не ставят своей целью довести uptime до 100%. Причина в том, что uptime в 99,99% вполне достаточен, чтобы продукты Google были исключительно надежны для реальных пользователей. А эту последнюю 0,01% добиться экспоненциально трудно, и бороться за неё просто нет смысла.


Следовательно, если это даёт в сумме 52 минуты даунтайма в год, Google будет пытаться подобраться как можно ближе к этой цифре; но всё, что меньше 52 минут в год, является упущенной возможностью взять на себя дополнительные риски и быстрее предоставить какие-либо перспективные фичи своим клиентам.


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



Если ваш технический долг находится в красной зоне, необходимо частично погасить его. Если он в зелёной зоне, вы можете взять на себя больше рисков и больше долга. Ваша цель — постоянно удерживать величину долга максимально близко к идеальной. Другими словами, если вы на пике красной части графика, идеальный бюджет технического долга A ⇒ B. Если вы во впадине зелёной части графика, то идеальный бюджет C ⇒ B. Помните лишь о том, что A ⇒ C — это слишком большой бюджет технического долга.


Так как технический долг может быть измерен (об этом мы писали в другой статье), эт�� все теперь не просто концепции — это полностью отвечает практическим потребностям.


Как выжать максимум из своего бюджета технического долга


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


Андреас Клингер, координатор удалённых команд в AngelList, хорошо излагает это в своей статье «Рефакторинг больших баз унаследованного кода»:


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


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


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


  • Выделите в своей кодовой базе файлы со слабым владением, поскольку владение кодом является ведущим показателем благополучия вашей кодовой базы. Подробнее об этом — в нашей статье «Одна особенность корпоративной культуры, необходимая для благополучия кодовой базы».
  • Измерьте связность (cohesion) и зацепление (coupling) для этих файлов и оставьте в списке лишь файлы со слабым владением, низкой связностью и высоким зацеплением. Вы можете узнать больше о каждом из этих показателей в нашей статье «Использование исследований лидеров отрасли для измерения технического долга».
  • Рассчитайте повторяющуюся активность (churn) для каждого из этих файлов, чтобы определить подмножество проблемных файлов. Как показало исследование Microsoft, активно изменяющиеся файлы составляют лишь 2–8% от общего объема файлов в системе, но на них приходится 20–40% всех изменений, и они ответственны за 60–90% всех багов.
  • Соотнесите полученный список файлов с вашими планами на квартал. Потребует ли какая-либо из фич, перечисленных в ваших планах, поработать над подмножеством проблемных файлов, которое вы очертили? Если да, поставьте цели, связанные с рефакторингом этих файлов, оцените необходимый объем работ и назначьте задачи на конкретных разработчиков, — желательно, на тех, которые являются владельцами соответствующих файлов. Впишите эту работу в свои планы.

Для начала гляньте наше бесплатное расширение VSCode — оно поможет вам постоянно отслеживать и выплачивать самые неотложные технические долги.


Вступите в долгосрочные отношения с техническим долгом


Мы внедрили данный подход, основанный на данных, в Stepsize, а также во многих софтверных компаниях мирового класса. Мало того, что тема технического долга стала теперь намного понятнее, так мы ещё и знаем, сколько долга мы готовы взять на себя, и когда/как его вернуть. Мы все редко задумываемся, правильно ли мы выбрали компромисс между новыми фичами и техническим долгом. Нам удалось устранить существенную часть догадок, а также множество страхов и беспокойств, сопровождавших данный выбор.


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


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