Технический долг (Technical Debt)
Накопленные компромиссы в коде и архитектуре, которые ускорили работу сейчас, но замедляют и удорожают каждое следующее изменение.
Технический долг (technical debt, сокращенно «техдолг») — метафора, которую в 1992 году предложил программист Уорд Каннингем. Когда команда выбирает быстрое, но не лучшее решение — без тестов, с копированием кода, с «временным» обходом, — она как бы берет кредит: функция выходит раньше. Но по кредиту приходится платить проценты: каждое следующее изменение в этом месте дается дольше и чаще приводит к ошибкам. Пока долг не погашен, проценты растут.
Откуда берется
- Осознанно — ради срока: «выпускаем к дате, потом переделаем». Это нормальное деловое решение, если долг записан и действительно возвращается.
- По незнанию — неудачная архитектура, которая стала понятна только со временем.
- Сам собой — устаревают библиотеки, фреймворки и версии языка; меняются требования, и старые решения перестают им соответствовать.
Как выглядит долг
- Нет автоматических тестов — любое изменение страшно трогать.
- Одна и та же логика скопирована в пять мест, и исправлять ее нужно везде.
- Устаревшие версии библиотек с известными уязвимостями.
- Модули, в которых разбирается один человек.
- Ручные операции при выпуске, которые давно пора автоматизировать.
Как он проявляется для бизнеса
Долг почти не виден в отчетах, но сильно заметен по результатам: простые доработки оцениваются в недели, после каждого выпуска что-то ломается, новые разработчики долго входят в проект, а исправление одной ошибки рождает две новые. В крайних случаях систему проще написать заново, чем развивать, — и тогда долг превращается в отдельный большой проект, например в миграцию на новую платформу.
Как управлять долгом
- Записывать. Долг ведут как обычные задачи в трекере: что именно, чем мешает, сколько стоит исправление.
- Выделять время постоянно. Распространенная практика — регулярно отдавать часть мощности команды, например 15–20%, на погашение долга, а не ждать «свободного месяца», который не наступит.
- Гасить по пути. Перед доработкой модуля сначала навести в нем порядок — «оставить место чище, чем было».
- Предотвращать. Код-ревью, автоматические тесты, CI/CD и регулярное обновление зависимостей.
Как говорить о долге с бизнесом
Фраза «нам нужно отрефакторить код» звучит как просьба потратить деньги впустую. Работает язык последствий: «изменения в модуле расчетов сейчас занимают три недели вместо одной, и каждый второй выпуск дает ошибку в отчетах; две недели на переработку вернут нормальную скорость и снизят риск». Технический долг — не провал команды, а обычная часть жизни любой долгоживущей системы. Опасен не сам долг, а долг, о котором никто не знает и который никто не возвращает.