Технический долг берёт проценты только с того кода, который меняют

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

Адам Торнхилл, основатель компании CodeScene и автор книг про анализ кода, описывал случай, когда коммерческий инструмент насчитал в системе 4 000 лет технического долга. Системе было 15 лет. Цифра страшная и бесполезная: с чего начинать, она не говорит.

Что такое технический долг на самом деле

Метафору придумал Уорд Каннингем, когда объяснял начальнику, зачем команда переделывает уже работающий код финансовой системы WyCash. В 1992 году он рассказал об этом на конференции OOPSLA. В 2009-м он записал видео, потому что метафору, по его словам, поняли неправильно.

Разрешения писать плохо в этой метафоре нет. Каннингем прямо говорит, что никогда не выступает за то, чтобы писать код плохо. Идея у него другая. Команда пишет код так, как понимает задачу сегодня, даже если понимает не до конца. Потом узнаёт о задаче больше. Если код не переделать под новое понимание, каждая следующая доработка спотыкается о старую ошибку в голове, которая теперь записана в программе. Это и есть проценты. А если только добавлять функции и ничего не перестраивать, рано или поздно проценты съедают всё, и работа встаёт.

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

Где по техническому долгу платят проценты

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

Места, где запутанный код ещё и часто меняют, он называет горячими точками (hotspots). По данным CodeScene на открытых проектах, приоритетные горячие точки занимают 2–3% кода. Их касается 11–16% всех изменений. И на них приходится от 25 до 70% найденных и исправленных дефектов.

Сколько стоят эти проценты, Торнхилл и Маркус Борг посчитали в исследовании Code Red на 39 коммерческих системах, больше 30 тысяч файлов. В коде низкого качества дефектов было в 15 раз больше, чем в чистом. Задачи там решались в среднем на 124% дольше, то есть больше чем вдвое. А самая долгая задача шла до девяти раз дольше, чем самая долгая в чистом коде.

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

Как объяснить технический долг бизнесу: словарь фраз

Разработчики описывают долг своими словами, и руководитель слышит в них то «дайте поиграть с кодом», то «всё пропало». Обычно за этими словами нет ни того, ни другого. Есть конкретное место в системе, и про него можно задать конкретный вопрос.

«Тут костыль». Временное решение, которое так и осталось. Само по себе не беда: возможно, его поставили осознанно, чтобы успеть к сроку. Вопрос тут один: когда команда пойдёт в это место снова? Если в ближайший квартал не пойдёт, костыль может постоять.

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

«Нам нужен спринт на рефакторинг». Рефакторинг — переделка кода без изменения того, что он делает для пользователя. Просьба честная, но слишком общая. Уточните, какие три места, что там станет быстрее и как вы это увидите через квартал. Хороший ответ звучит так: «доработки в модуле оплаты сейчас идут вдвое дольше оценки, после переделки должны укладываться». Плохой — «код станет чище».

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

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

Долг, который растёт сам

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

Технический директор одного из направлений «Фланта» рассказывал о микросервисе, которому было около полутора лет. Его обновление заняло 14 дней: пришлось поменять половину зависимостей и 30% кода. Выходом стала утилита Dependabot, которая сама предлагает обновления. Держать проект в актуальном состоянии стало стоить инженеру 10–15 минут в неделю.

Две недели против пятнадцати минут в неделю. Такой долг выгоднее отдавать по расписанию и маленькими порциями, чем ждать, пока придётся обновлять всё разом. И это единственный вид долга, который стоит держать в порядке даже в коде, куда никто не ходит. Особенно там, где через него проходят чужие данные: о безопасности кода есть отдельный чек-лист.

«Проще переписать с нуля»: когда это правда

Почти никогда. Самый известный пример — Netscape. В 2000 году Джоэл Спольски написал о том, как компания Netscape взялась переписывать свой браузер с нуля. Версии 5.0 так и не было, а между 4.0 и 6.0 прошло почти три года. Доля рынка за это время сильно упала. Переписывание с нуля Спольски назвал худшей стратегической ошибкой, какую может совершить компания-разработчик.

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

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

Как уменьшать технический долг: сколько времени отдавать

Чаще всего советуют отдавать долгу 10–20% времени команды. В опросе McKinsey 2020 года ИТ-директора крупных финансовых и технологических компаний оценили, что на долг и так уходит 10–20% бюджета, выделенного на новые продукты. А разработчики в опросе Stripe 2018 года говорили, что на техдолг у них уходит 13,5 часа из 41 рабочего в неделю. Треть недели.

То есть вопрос «давать ли время на долг» не совсем честный. Время уже уходит. Вопрос в том, уходит ли оно по плану или в виде сорванных сроков.

Фиксированный процент «на всё» плох тем, что его легко потратить на код, который никто не трогает. Надёжнее такая договорённость:

1. Раз в квартал команда называет пять–десять мест, где больше всего задач, ошибок и сорванных сроков. Источник — трекер задач и история репозитория.
2. Для каждого места записывают, во сколько раз там дольше идут задачи и как часто туда приходит работа.
3. Задачу в горячей точке оценивают вместе с расчисткой. Расчистку делают перед доработкой, пока разработчик всё равно в этом коде.
4. Обновление библиотек и платформы идёт по расписанию, маленькими порциями, отдельной строкой.
5. Через квартал сравнивают сроки задач в этих местах с прошлыми. Не стали короче — разговор о долге стоит начать заново.

Быстрая проверка, идут ли у вас проценты:

Код, который никто не открывает

В любой системе старше пары лет есть модули, написанные плохо. Их писали в спешке, люди, которые давно ушли, по требованиям, которых уже никто не помнит. Они работают. Их никто не открывает.

Это ужасный код. И он почти ничего не стоит.

Тратить на него время ради порядка — то же самое, что досрочно гасить кредит, по которому не начисляют проценты. Красиво, но деньги нужнее в другом месте.

Деньги уходят туда, куда команда ходит каждую неделю. Туда и стоит нести время на рефакторинг. Остальное пусть лежит, пока не понадобится. Когда понадобится, оно само окажется в списке горячих точек.