Технический долг (Technical Debt)

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

Технический долг (technical debt, сокращенно «техдолг») — метафора, которую в 1992 году предложил программист Уорд Каннингем. Когда команда выбирает быстрое, но не лучшее решение — без тестов, с копированием кода, с «временным» обходом, — она как бы берет кредит: функция выходит раньше. Но по кредиту приходится платить проценты: каждое следующее изменение в этом месте дается дольше и чаще приводит к ошибкам. Пока долг не погашен, проценты растут.

Откуда берется

  • Осознанно — ради срока: «выпускаем к дате, потом переделаем». Это нормальное деловое решение, если долг записан и действительно возвращается.
  • По незнанию — неудачная архитектура, которая стала понятна только со временем.
  • Сам собой — устаревают библиотеки, фреймворки и версии языка; меняются требования, и старые решения перестают им соответствовать.

Как выглядит долг

  • Нет автоматических тестов — любое изменение страшно трогать.
  • Одна и та же логика скопирована в пять мест, и исправлять ее нужно везде.
  • Устаревшие версии библиотек с известными уязвимостями.
  • Модули, в которых разбирается один человек.
  • Ручные операции при выпуске, которые давно пора автоматизировать.

Как он проявляется для бизнеса

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

Как управлять долгом

  • Записывать. Долг ведут как обычные задачи в трекере: что именно, чем мешает, сколько стоит исправление.
  • Выделять время постоянно. Распространенная практика — регулярно отдавать часть мощности команды, например 15–20%, на погашение долга, а не ждать «свободного месяца», который не наступит.
  • Гасить по пути. Перед доработкой модуля сначала навести в нем порядок — «оставить место чище, чем было».
  • Предотвращать. Код-ревью, автоматические тесты, CI/CD и регулярное обновление зависимостей.

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

Фраза «нам нужно отрефакторить код» звучит как просьба потратить деньги впустую. Работает язык последствий: «изменения в модуле расчетов сейчас занимают три недели вместо одной, и каждый второй выпуск дает ошибку в отчетах; две недели на переработку вернут нормальную скорость и снизят риск». Технический долг — не провал команды, а обычная часть жизни любой долгоживущей системы. Опасен не сам долг, а долг, о котором никто не знает и который никто не возвращает.