Вы знаете, каково это. Впихнуть всё необходимое в спринт и так весьма непросто, а ведь ещё нужно где-то найти дополнительные 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, а также во многих софтверных компаниях мирового класса. Мало того, что тема технического долга стала теперь намного понятнее, так мы ещё и знаем, сколько долга мы готовы взять на себя, и когда/как его вернуть. Мы все редко задумываемся, правильно ли мы выбрали компромисс между новыми фичами и техническим долгом. Нам удалось устранить существенную часть догадок, а также множество страхов и беспокойств, сопровождавших данный выбор.

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

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