Содержание
Технический долг это все компромиссы в коде и архитектуре, которые команда приняла ради скорости и которые придётся исправлять позже. Как у обычного кредита, у него есть тело и проценты: тело это работа по исправлению, а проценты это время, которое команда каждую неделю теряет, обходя старые решения. Пока проценты маленькие, долг полезен: он позволяет запуститься быстрее. Опасным он становится, когда проценты съедают заметную часть бюджета на разработку, и этот момент легко пропустить.
Технический долг простыми словами
Термин придумал программист Уорд Каннингем в 1992 году, чтобы объяснить руководству, зачем тратить время на переделку работающего кода. Метафора оказалась точной.
Представьте, что к сезону нужно запустить новый способ оплаты. Правильно сделать за месяц не успеваем, поэтому делаем за неделю: без тестов, с копированием кода из соседнего модуля, с ручной настройкой на сервере. Мы взяли в долг три недели. Продажи пошли вовремя, и это было правильное решение.
Но теперь каждый раз, когда кто-то трогает оплату, он тратит лишний час: разобраться в копии кода, проверить руками, не забыть про ручную настройку. Это проценты. Если долг не погасить, проценты идут годами, а новые долги наслаиваются на старые.
Технический долг в IT бывает не только в коде:
- Код: дублирование, запутанная логика, отсутствие тестов.
- Архитектура: система не делится на части, всё связано со всем, не выдерживает рост.
- Инфраструктура: ручная выкладка, сервер, настроенный вручную, нет мониторинга.
- Зависимости: устаревшие версии PHP, CMS, библиотек без обновлений безопасности.
- Знания: нет документации, систему понимает один человек.
Откуда берётся технический долг
Мартин Фаулер предложил делить долг по двум признакам: осознанный он или случайный, разумный или безрассудный.
Разумный осознанный долг нормальная часть бизнеса: вы сознательно выбираете скорость и знаете, что потом придётся доделать. Опасен долг, о котором никто не знает. Он копится тихо и проявляется уже сбоями и сорванными сроками.
Сколько стоит технический долг
Долг в коде легко перевести в деньги. Stripe опросил тысячи разработчиков и руководителей для исследования The Developer Coefficient, и цифры показательны.
Посчитайте на своей команде. Если разработка обходится в 1 200 000 ₽ в месяц, а треть времени уходит на обход старых решений, около 400 000 ₽ в месяц вы платите процентами по долгу. Эти деньги не видны в бюджете отдельной строкой. Они прячутся в сроках: задача, которая на чистом коде заняла бы два дня, занимает неделю.
У долга есть и вторая цена, которую сложнее посчитать заранее: аварии. Устаревший компонент без обновлений безопасности однажды становится точкой взлома. Ручная выкладка однажды выкатывает не ту версию в пятницу вечером.
Как понять, что долг стал опасным
Тревожные сигналы видны и без технической экспертизы. Достаточно наблюдать за работой команды пару месяцев.
| Сигнал | Как заметить | Что это значит |
|---|---|---|
| Доработки дорожают | Похожие задачи с каждым разом занимают больше времени | Проценты по долгу растут |
| Сбои повторяются | Одна и та же проблема возвращается после «исправления» | Чинят симптомы, а не причину |
| Страх изменений | Команда просит не трогать какой-то модуль | Код без тестов и без понимания |
| Долгий вход новичков | Новый разработчик полезен только через несколько месяцев | Нет документации, логика запутана |
| Обновления откладываются | Версии PHP, CMS и библиотек годами не меняются | Растёт риск безопасности и потолок для роста |
| Оценки сроков не сбываются | Задачи регулярно выходят за оценку в разы | Никто не знает, что сломается по пути |
Если совпадают три сигнала и больше, долг перешёл из инструмента в проблему. Часто это значит, что система уже стала легаси, подробнее в статье «Легаси: что это такое и что делать бизнесу».
Как избавиться от технического долга
Избавиться от долга полностью нельзя и не нужно. Нужно им управлять, как любым другим долгом компании.
- Составьте реестр. Список известных проблем: что не так, чем мешает, сколько стоит исправить. Без реестра долг гасится только после аварий.
- Расставьте приоритеты. Оценивайте каждый пункт по двум осям: насколько он мешает бизнесу и сколько стоит исправить.
- Выделите постоянную долю времени. Многие команды закладывают на погашение долга фиксированную часть каждого цикла разработки. Так долг не растёт, а бизнес не ждёт месяцами.
- Гасите там, где работаете. Дорабатываете модуль, заодно приводите его в порядок. Это дешевле, чем отдельный проект «рефакторинг».
- Чините первопричины. Если сбой повторяется, ищите, почему он возник, а не только чините последствия. Как это делать, разобрали в статье про root cause analysis.
Когда техдолг гасить не нужно
Не каждый долг стоит возвращать.
- Часть системы скоро уйдёт. Модуль, который через полгода заменят, достаточно поддерживать в рабочем состоянии.
- Код не меняется. Некрасивый, но стабильный модуль, к которому никто не прикасается, не начисляет процентов.
- Эксперимент. Если функция может не взлететь, тратить время на идеальный код рано.
Главное, чтобы такие решения принимались осознанно и были записаны.
Как оценить технический долг в вашей системе
Своя команда часто видит долг изнутри, но ей трудно оценить его масштаб и объяснить бизнесу в деньгах. К тому же у неё нет времени: срочные задачи всегда важнее.
Внешний технический аудит решает эту задачу за несколько недель: на выходе реестр долга с приоритетами, оценкой стоимости исправления и планом работ. Отчёт остаётся у вас, по нему может работать ваша команда или мы на поддержке, где погашение долга идёт параллельно с задачами бизнеса.
Частые вопросы
Что такое технический долг простыми словами?
Это работа, которую команда отложила ради скорости: тесты, правильная архитектура, обновления. Пока она не сделана, каждая новая задача стоит дороже, как проценты по кредиту.
Технический долг это всегда плохо?
Нет. Осознанный долг помогает запуститься быстрее, и это нормальный бизнес-компромисс. Плохо, когда долг не записан, не оценён и не гасится, тогда проценты растут незаметно.
Как измерить технический долг?
Через реестр известных проблем с оценкой стоимости исправления и через косвенные метрики: время на типовые задачи, долю времени на исправление ошибок, частоту повторяющихся сбоев, срок входа новых разработчиков.
Сколько времени выделять на погашение долга?
Универсальной цифры нет, она зависит от возраста и состояния системы. Важнее регулярность: небольшая постоянная доля каждого цикла работает лучше, чем редкие большие проекты по рефакторингу.
Чем технический долг отличается от легаси?
Технический долг это конкретные отложенные исправления. Легаси это состояние системы целиком, когда долг накопился, а знания о системе потеряны. Долг можно погасить, легаси нужно сначала понять.
