Технический долг: что это и как его снизить

В начале жизни приложения новая функция добавляется быстро. Через пару лет такое же по размеру изменение занимает втрое больше времени, а после каждого релиза приходится чинить то, чего никто не трогал. Разработчик говорит «это сложно изменить», и никто не может толком объяснить почему.

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

Откуда берётся технический долг

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

Самые частые источники:

• Необновлённые компоненты. Фреймворк, библиотеки и серверное ПО отстают на несколько версий. Каждое пропущенное обновление делает следующее больше и рискованнее.
• Скопированный код. Одна и та же логика в пяти местах, каждый раз немного по-разному. Исправление в одном месте не доходит до остальных.
• Нет тестов. Никто не может перед релизом проверить, не сломало ли изменение что-то в другом месте.
• Незадокументированные решения. Почему таблица устроена именно так? Почему эта функция вызывает три других? Ответ ушёл вместе с разработчиком.
• Временные решения. «Пока сделаем так, потом приведём в порядок». Потом так и не наступило.

Как распознать технический долг

Чтобы заметить долг, не нужно самому читать код. Бизнес-симптомы часто нагляднее:

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

Если верно три пункта или больше, долг, скорее всего, уже больше бюджета новой разработки.

Как оценить долг

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

1. Возраст компонентов. Какие фреймворки и библиотеки больше не поддерживаются и в каких есть известные уязвимости.
2. Зоны риска. Части, где изменения вызывают больше всего ошибок и которые меняют чаще всего. Там исправление окупается лучше всего.
3. Зависимости. Что вызывает что и требует ли замена одной части изменения десяти других.
4. Состояние тестов и документации. Какую часть системы можно проверить, не прокликивая всё вручную.

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

Как снизить долг, не останавливая бизнес

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

Разумнее поэтапный подход:

• Начните с безопасности. Неподдерживаемые компоненты и известные уязвимости — прежде всего остального.
• Исправляйте там, где сейчас работаете. Если новая функция затрагивает какой-то модуль, приведите этот модуль в порядок заодно. Так долг уменьшается там, где он реально стоит денег.
• Добавляйте тесты перед изменением. Сначала тесты вокруг рискованной части, потом изменение. Так сразу видно, если что-то сломалось.
• Заменяйте по частям. Старый модуль заменяется новым, пока не будут заменены все части. После каждого шага у вас работающее приложение.
• Документируйте по ходу. Каждое решение записывается, чтобы следующему человеку не пришлось начинать с нуля.

Сколько времени отводить на снижение долга

Хорошее эмпирическое правило — оставлять часть каждого цикла разработки на наведение порядка, а не откладывать это в проект «когда-нибудь потом». Если долг уже настолько велик, что новые функции невозможно добавить за разумное время, нужен отдельный этап модернизации. Тогда какое-то время придётся больше наводить порядок, чем разрабатывать новое.

Итог

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

Если ваше приложение дошло до точки, где каждое изменение дорого и рискованно, посмотрите, как я занимаюсь модернизацией и развитием ПО, или опишите свою ситуацию. Скажу честно, стоит ли приводить приложение в порядок или разумнее построить что-то новое.