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

Определение

Метафору придумал Уорд Каннингем в 1992 году, в докладе об опыте разработки системы WyCash на конференции OOPSLA: по его словам, выпустить код в первой версии значит влезть в долг, и небольшой долг ускоряет разработку, пока его быстро возвращают, переписывая код. Основной долг это работа, которая нужна, чтобы исправить срезанный угол. Проценты это дополнительные усилия, которые платят при каждом следующем изменении этого кода, пока основной долг не погашен. Позже Каннингем объяснял, что никогда не имел в виду разрешение писать плохой код: смысл в том, чтобы код отражал ваше текущее понимание задачи, пусть и неполное, и менялся по мере того, как понимание растет. Квадрант технического долга Мартина Фаулера (2009) делит долг по двум осям: безрассудный или разумный, намеренный или ненамеренный. «У нас нет времени на проектирование» это безрассудный и намеренный долг. Выпустить сейчас, понимая, во что обойдется срезанный угол, это разумный и намеренный долг. «Теперь мы знаем, как надо было это построить» это разумный и ненамеренный долг, и он случается даже у хороших команд.

Почему это важно

Признаки узнаваемы: оценки для мелких правок все растут, исправление в одном месте ломает другое, только один разработчик решается трогать определенную часть, а команда начинает просить все переписать. Долг не всегда ошибка. Срезанный угол, который вовремя выводит на рынок MVP (простую первую версию для проверки), бывает верным решением, а прототип, который выбросят, вообще не нужно гасить. Опасен долг, который никто не решал брать и никто не отслеживает. Гипотеза Фаулера о «выносливости дизайна» (2007) описывает эту закономерность: вложения в хороший дизайн позволяют команде дольше работать в высоком темпе, а запущенный дизайн кажется быстрее только поначалу. Код, который написал ИИ и никто не прочитал, как при вайб-кодинге, это долг с первого дня.

Напрямую связано: Вайб-кодинг (Vibe Coding), Git (система контроля версий), MVP (минимально жизнеспособный продукт).

Советы по улучшению

• Ведите видимый список известного долга в бэклоге, рядом с функциями, чтобы он открыто боролся за время.
• Гасите долг в той части, которую все равно собираетесь менять: там самые высокие проценты.
• Выделяйте фиксированную долю времени разработки на крупные пункты и дайте команде предложить ее размер, потому что никакое исследование не задает конкретную цифру.
• Осознанно решайте, какой долг оставить, например долг в прототипе, который выбросят.
• Просите автоматические тесты перед чисткой, чтобы рефакторинг (перестройка кода без переписывания с нуля) не сломал то, что уже работает.

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

• Игнорировать долг, пока мелкие правки не начнут занимать недели, а переписывание не покажется единственным выходом.
• Считать долг проблемой одних разработчиков, хотя он проявляется в более медленной работе и более высоких расходах.
• Срезать угол и не записать это, так что никто не вспомнит, что долг надо вернуть.
• Верить, что фиксированный процент времени на долг это доказанное правило, хотя никакое исследование его не задает.