Технический долг: управление

Технический долг (technical debt) — метафора для дополнительной работы, возникающей из-за выбора быстрых или несовершенных решений вместо лучших, требующих больше времени.

Зачем нужно

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

Где используется

Любой продакшн-проект — всегда присутствует
Sprint Planning — планирование задач на рефакторинг
Ретроспектива — выявление накапливающихся проблем
Разговор с PO — объяснение нетехнических расходов

Типы технического долга

Намеренный (deliberate):
  Знаем что решение не идеально, но осознанно выбрали
  "Захардкодим URL API сейчас, вынесем в конфиг позже"
  → Нормально если задокументировано и выплачивается

Ненамеренный (inadvertent):
  Не знали лучшего способа когда писали
  "Не знали о connection pooling, сделали по-старому"
  → Нормально для обучающихся, нужно исправлять

Гниение (bit rot):
  Код правильный, но технологии устарели
  "jQuery 1.9 в проекте 2026 года"
  → Накапливается незаметно, требует стратегии

Как измерить техдолг

Метрики кода:
  Цикломатическая сложность (complexity) > 10 → тревога
  Дублирование кода (duplication) > 5% → нужен рефакторинг
  Покрытие тестами < 60% → высокий риск

Инструменты:
  SonarQube — анализ качества кода
  ESLint complexity rule
  GitHub Code Climate

"Ощущение команды":
  "Страшно трогать этот файл" — классический признак
  "Добавить функцию занимает 3 дня" — тоже признак

Стратегии управления

Boy Scout Rule

"Всегда оставляй код чище, чем нашёл"

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

Накопительный эффект: через месяц модуль значительно чище

Технический долг в бэклоге

Создай отдельный backlog для техдолга:
  TECH-001: Вынести SQL-запросы в репозиторий-паттерн
  TECH-002: Обновить axios с 0.27 до 1.x
  TECH-003: Добавить типы TypeScript к auth-модулю

Приоритизация:
  Блокирует новые фичи? → P1 (высокий)
  Замедляет разработку? → P2 (средний)
  Эстетический/стиль?  → P3 (низкий)

Правило 20%:
  20% ёмкости каждого спринта — на техдолг

Объяснение бизнесу

НЕ говори: "Нам нужно время на рефакторинг"
           (бизнес не понимает что это)

ГОВОРИ:
  "Добавление новой фичи авторизации сейчас займёт 2 недели.
   Если потратим 3 дня на упрощение кода —
   та же фича займёт 3 дня. Это инвестиция."

Аналогия: технический долг = финансовый долг
  Проценты = замедление разработки
  Выплата = рефакторинг
  Банкротство = "переписать всё с нуля"

Частые ошибки

Ошибка	Проблема	Решение
"Потом перепишем" без тикета	Никогда не перепишем	Сразу создать TECH-задачу в бэклоге
Полный рефакторинг вместо итеративного	Никогда не закончим	Рефакторить малыми шагами, рядом с задачей
Не сообщать о техдолге PO	PO не видит скрытых затрат	Регулярно сообщать о замедлении из-за долга
Добавлять техдолг бездумно	Долг растёт быстрее чем выплачивается	Отслеживать и балансировать