Технический долг: когда рефакторить, а когда терпеть
Не всякий беспорядок в коде надо исправлять. Разбираем, как считать стоимость технического долга и по каким признакам понимать, что дальше терпеть дороже.
Разговор про технический долг обычно устроен так: разработчики говорят «здесь надо всё переписать», бизнес слышит «два месяца без новых функций» и отказывает. Через год те же разработчики называют срок в четыре месяца, и разговор повторяется.
Проблема в том, что обе стороны обсуждают код, а обсуждать надо деньги и скорость. Технический долг — это не «некрасивый код», а разница между тем, сколько доработка стоит сейчас, и тем, сколько она стоила бы в порядке.
Что долгом не является
- Код, написанный не в вашем любимом стиле, но понятный и покрытый проверками
- Простое решение в месте, которое не меняется годами
- Устаревшая библиотека, которая работает, поддерживается и не имеет уязвимостей
- Дублирование в двух местах, если эти места живут по разным правилам
Всё это — нормальные компромиссы. Рефакторинг участка, который никто не трогает, не ускоряет ничего и не экономит денег: он просто тратит время на приведение в порядок того, что и так не мешает.
Признаки настоящего долга
| Симптом | Что за ним стоит | Последствие |
|---|---|---|
| Оценки задач растут при том же объёме | Каждая правка задевает лишнее | Планирование перестаёт работать |
| Одна правка ломает несоседний участок | Нет границ между частями | Правки боятся вносить |
| Только один человек может править участок | Знание не в коде, а в голове | Отпуск превращается в риск |
| Проверки перед выпуском только руками | Нет автоматических тестов | Выпуск редкий и напряжённый |
| Новичок выходит на работу месяцами | Логика размазана и не описана | Команду сложно расширять |
Первая строка — самая показательная. Если полгода назад похожая задача занимала три дня, а сейчас восемь, разница и есть процент по долгу. Её можно посчитать в деньгах и сравнить со стоимостью рефакторинга.
Как считать стоимость
type DebtEstimate = {
tasksPerMonth: number // сколько задач в месяц идёт через проблемный участок
extraHoursPerTask: number // сколько лишних часов уходит из-за состояния кода
hourlyRate: number
refactorHours: number // оценка работ по приведению в порядок
}
export function paybackMonths(e: DebtEstimate): number {
const monthlyLoss = e.tasksPerMonth * e.extraHoursPerTask * e.hourlyRate
const refactorCost = e.refactorHours * e.hourlyRate
if (monthlyLoss === 0) return Infinity // участок не трогают — платить нечем
return refactorCost / monthlyLoss
}
// Срок окупаемости до полугода — берём в работу.
// Больше двух лет — участок либо трогают редко,
// либо переписывать надо не егоТакой расчёт переводит разговор из вкусовщины в плоскость сроков. «Переписать модуль заказов за 120 часов, окупится за четыре месяца» — предложение, на которое бизнес может ответить осмысленно.
Как встроить в работу
- Держать постоянную долю времени на технические задачи — обычно от 15 до 20 процентов
- Приводить в порядок то, что трогаете по текущей задаче, а не то, что просто не нравится
- Крупные куски выносить в отдельные задачи с оценкой окупаемости
- Перед рефакторингом покрывать участок проверками, иначе изменения нечем подтвердить
- Фиксировать до и после: время на похожие задачи, число возвратов в работу
Постоянная доля работает лучше периодических «недель рефакторинга»: долг накапливается непрерывно, и разбирать его тоже надо непрерывно. Отдельные недели обычно первыми уходят под срочные задачи.
Технический долг похож на кредит: небольшой и обслуживаемый — рабочий инструмент, забытый и растущий — причина, по которой проект однажды становится дешевле переписать.
Частые вопросы
- Как объяснить бизнесу необходимость рефакторинга
- Через скорость и деньги, а не через качество кода. Сравните оценки похожих задач полгода назад и сейчас, посчитайте разницу в часах и умножьте на ставку. Дальше сопоставьте с оценкой работ — получится срок окупаемости, который можно обсуждать.
- Переписать с нуля или рефакторить постепенно
- Постепенно, за редкими исключениями. Переписывание оправдано, когда меняется сама модель работы продукта или технология больше не поддерживается. В остальных случаях поэтапная замена частей за работающим интерфейсом дешевле и безопаснее.
- Сколько времени выделять на технические задачи
- От 15 до 20 процентов ресурса команды на постоянной основе. При меньшей доле долг накапливается быстрее, чем разбирается, при большей — заметно замедляется развитие продукта. Долю стоит поднимать временно, если оценки задач начали расти.
Похожая задача в вашем проекте?
Разберём вашу ситуацию и пришлём оценку по этапам — без обязательств и общих слов.
Обсудить задачу
