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

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

Откуда он берётся

Часть долга появляется сознательно. Перед запуском срок важнее, и что-то делают временно: прямой запрос в базу вместо нормального обмена, копия кода вместо общего модуля. Это нормальная сделка, если её потом закрывают.

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

Третья часть возникает из-за времени. Библиотеки и платформа выходят в новых версиях, старые перестают получать исправления безопасности. Если их не обновлять, через два-три года обновление становится отдельным проектом.

Признаки, которые видно без кода

Простые правки дорожают. Новое поле в форме оценивают в неделю. Год назад это был день.

Исправления ломают соседнее. После каждого релиза всплывают ошибки там, где ничего не меняли.

Один человек знает, как это работает. Если он в отпуске, правки ждут.

Обновления откладывают. Разработчики говорят, что обновлять версии опасно, и откладывают это из квартала в квартал.

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

Сколько времени на него закладывать

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

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

Когда переписывать

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

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

Частые вопросы

Как понять, честно ли подрядчик говорит о долге? Попросите список конкретных мест с оценкой, сколько времени каждое отнимает на доработках сейчас. Общие слова о том, что «код плохой», ничего не значат.

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

Можно ли не тратить на это деньги? Можно какое-то время. Потом каждая доработка дорожает, и вы всё равно платите за долг, только незаметно и с процентами.

Правило

Следите за тем, сколько стоят одинаковые по объёму правки. Если они дорожают из года в год, система копит долг, и на его разбор нужно выделить постоянную часть времени разработчиков.