Технический долг: что это, почему накапливается и как им управлять

TL;DR. Технический долг — это цена быстрых решений в коде и архитектуре, которая со временем растёт, как проценты по кредиту: каждое следующее изменение даётся дороже. Полностью избежать его нельзя, опасен только неуправляемый долг. Чтобы держать его под контролем, долг измеряют, ведут отдельный бэклог, выделяют на погашение 15–20% ресурса команды и гасят инкрементным рефакторингом, не останавливая релизы.

Технический долг съедает треть рабочего времени разработчиков. В исследовании Stripe и Harris Poll «The Developer Coefficient» (2018) опросили больше тысячи разработчиков и столько же топ-менеджеров. Выяснилось, что из средней рабочей недели в 41,1 часа на технический долг уходит 13,5 часа, а вместе с разбором «плохого кода» — 17,3 часа, то есть около 42% времени. Авторы оценили потери мировой экономики примерно в $300 млрд в год. McKinsey в опросе CIO крупных компаний (2020) получил похожую картину: техдолг составляет 20–40% стоимости всего технологического ландшафта, а 10–20% бюджета на новые продукты тратится на проблемы, которые он создаёт.

Метафору технического долга предложил программист Уорд Каннингем ещё в 1992 году. Смысл простой: быстрое решение похоже на кредит — деньги (время) вы получаете сразу, но потом платите проценты, пока не вернёте тело. Проблема не в самом долге, а в том, что его часто никто не считает. Поэтому любой разговор о модернизации продукта мы начинаем с цифр: аудит и рефакторинг legacy-кода показывает, где долг реально тормозит бизнес, а где с ним можно спокойно жить.

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

Что такое технический долг простыми словами

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

Метафора кредита здесь работает почти буквально:

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

Пример из практики. В интернет-магазине логика расчёта скидок скопирована в пять мест: корзину, карточку товара, мобильное API, письма и админку. Новое правило скидки вместо двух дней занимает пять, потому что правку нужно внести везде, а потом вручную проверить, что ничего не разъехалось. Три лишних дня — это и есть проценты по долгу, и они будут начисляться при каждом следующем изменении.

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

Откуда взялся термин и почему это не ругательство

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

Позже Мартин Фаулер уточнил границу понятия: «A mess is not a debt» — беспорядок не равен долгу. Долг — это осознанное или хотя бы объяснимое решение, у которого есть цена. Небрежный код, написанный без понимания, — это уже не кредит, а просто плохая работа.

Отсюда главный вывод: технический долг — не ругательство, а инструмент. Иногда взять его — лучшее решение для бизнеса:

• Проверка гипотезы. Если неизвестно, нужна ли функция пользователям, нет смысла строить для неё идеальную архитектуру.
• MVP и первый запуск. Выйти на рынок за три месяца с упрощённым решением часто выгоднее, чем за девять — с безупречным.
• Окно рынка или жёсткий дедлайн. Выставка, сезон, требование регулятора — в таких случаях скорость стоит дороже чистоты кода.

Условие одно: долг фиксируется и возвращается. Если после запуска MVP команда сразу переходит к следующим фичам и не закладывает время на погашение, разумный кредит превращается в хронический.

Какие бывают виды технического долга

Виды технического долга различают по двум признакам: по тому, как он возник (осознанно или нет, разумно или безрассудно), и по тому, где он живёт — в коде, архитектуре, тестах, документации или инфраструктуре. Первая классификация помогает понять причину, вторая — спланировать работу.

Квадрант Фаулера: осознанный и неосознанный долг

Мартин Фаулер предложил делить долг по двум осям: осознанный или неосознанный, разумный или безрассудный. Получается матрица 2×2, где у каждой ячейки есть характерная «реплика команды».

	Безрассудный	Разумный
Осознанный	«На проектирование нет времени, пишем как получится» — долг берут без плана погашения.	«Выпускаем сейчас, а последствия разберём в следующем спринте» — долг взят ради скорости и записан в бэклог.
Неосознанный	«Что такое слоистая архитектура?» — команде не хватает квалификации, и долг появляется незаметно.	«Теперь мы понимаем, как это надо было сделать» — знание пришло в процессе работы над продуктом.

Фаулер подчёркивает, что разумно-неосознанный долг неизбежен: даже сильная команда лучше понимает задачу к концу проекта, чем в начале. Опасны прежде всего безрассудные ячейки — их нужно устранять процессами (code review, стандарты, обучение), а не только рефакторингом.

Виды долга по месту возникновения

Вид	Как проявляется	Пример
Кодовый	Дублирование, длинные функции, запутанные условия, «магические» значения	Одна и та же валидация телефона скопирована в семь форм
Архитектурный	Модули жёстко связаны, нельзя изменить одну часть, не задев другие	Монолит, где заказ, склад и оплата живут в одной таблице и одном классе
Долг тестирования	Мало автотестов, регресс проверяют руками, релиз — лотерея	Покрытие 5%, перед каждым релизом тестировщик два дня прокликивает сценарии
Долг документации	Знания живут в головах, онбординг долгий, API не описано	Интеграцию с 1С понимает один разработчик, который собирается уходить
Инфраструктурный и долг зависимостей	Устаревшие фреймворки, EOL-версии языка, библиотеки с известными уязвимостями	Проект на версии PHP, которая давно не получает обновлений безопасности
Процессный	Нет CI, code review, единых стандартов и Definition of Done	Код попадает в прод прямо с ноутбука разработчика
Дизайн- и UX-долг	Разнобой компонентов, устаревшие паттерны интерфейса	Пять разных стилей кнопок на одном сайте

Самый дорогой вид — архитектурный: его нельзя погасить точечной правкой, а проценты по нему платит каждая новая функция. Подробнее о том, как архитектурный выбор влияет на стоимость развития, мы писали в статье «Микросервисы или монолит».

Почему накапливается технический долг: 7 причин

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

1. Давление сроков и «запуск любой ценой». Жёсткий дедлайн без последующего окна на доработку — главный источник осознанного долга.
2. Экономия на архитектуре на старте. Проект начинают как «маленький сайт», а через год он становится ядром бизнеса с интеграциями, под которые его никто не проектировал.
3. Нет code review и стандартов. Каждый разработчик пишет в своём стиле, решения не обсуждаются, ошибки проектирования никто не замечает вовремя.
4. Нет автотестов. Без тестов рефакторинг страшен, поэтому код не улучшают, а обходят — и долг копится слоями.
5. Смена команды и потеря экспертизы. Уходят люди, которые понимали, почему система устроена именно так; новые боятся трогать непонятное и пишут «рядом».
6. Устаревание технологий. Долг появляется сам по себе: фреймворк, актуальный пять лет назад, сегодня не поддерживается, а его обновление с каждым годом дорожает.
7. Изменение требований бизнеса. Компания меняет модель — добавляет маркетплейс, подписку, новые регионы, — а система была спроектирована под старые сценарии.

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

Как понять, что у проекта техдолг: признаки

Признаки технического долга — это симптомы, которые видны даже без чтения кода: по срокам, качеству релизов и поведению команды. Проверьте свой проект по чек-листу:

• Простые с точки зрения бизнеса фичи оцениваются неделями, а оценки постоянно срываются.
• Каждое изменение ломает что-то в соседнем модуле.
• Растёт число регрессионных багов — старые ошибки возвращаются после новых релизов.
• В команде есть зоны «туда лучше не трогать» и код, который понимает один человек.
• Онбординг нового разработчика занимает больше месяца.
• Фреймворк или язык устарели, а библиотеки содержат известные уязвимости.
• Нет автотестов и CI — сборка и проверка делаются вручную.
• Релизы редкие, большие и страшные, их проводят ночью «на всякий случай».
• Затраты на серверы растут быстрее, чем нагрузка и выручка.
• Разработчики чаще говорят «это сложно из-за старого кода», чем обсуждают саму задачу.

Если совпало три и больше пункта — долг уже влияет на скорость и бюджет. Это повод провести аудит и посчитать его в часах, а не спорить на уровне ощущений.

Чем опасен технический долг для бизнеса

Последствия технического долга для бизнеса — это рост стоимости и сроков каждой доработки, увеличение числа сбоев и потеря способности быстро реагировать на рынок. Долг не виден в бухгалтерии, но проявляется в каждой строке бюджета разработки. Те самые 33% времени из исследования Stripe — это треть фонда оплаты труда команды, которая уходит не на новые возможности продукта.

• Падение скорости (time-to-market). Конкуренты выпускают функции за недели, вы — за месяцы.
• Рост стоимости каждой фичи. Проценты по долгу закладываются в оценку любой задачи, и бюджет раздувается незаметно.
• Инциденты и простои. Хрупкая система падает от неожиданных сочетаний, а восстановление занимает часы.
• Уязвимости безопасности. Устаревшие зависимости с известными CVE — прямой путь к утечке данных и штрафам.
• Выгорание и текучесть команды. Сильные разработчики уходят с проектов, где приходится бесконечно чинить, а не создавать.
• Блокировка масштабирования. Выход в новые регионы, рост нагрузки или новая бизнес-модель упираются в архитектуру, которая этого не выдерживает.

Кейс Knight Capital: 45 минут, которые стоили $440 млн

Самый известный пример — американский маркет-мейкер Knight Capital. 1 августа 2012 года компания выкатывала новое торговое ПО. В коде оставалась старая неиспользуемая функция Power Peg, а флаг, который раньше её включал, переиспользовали для новой логики. Обновление вручную раскатали на семь серверов из восьми. На восьмом заработал старый код и за примерно 45 минут отправил на биржу лавину ошибочных заявок.

Итог — около $440 млн убытков, что поставило компанию на грань банкротства. В постановлении SEC по этому делу разобраны причины: мёртвый код, который годами не удаляли, и ручной деплой без автоматических проверок. Это два классических вида долга — кодовый и процессный. Каждый по отдельности выглядел безобидно, а вместе они обошлись дороже, чем стоила бы любая модернизация.

Как измерить технический долг

Измерить технический долг — значит перевести его из ощущений команды в числа, понятные бизнесу: часы на исправление, долю времени спринта, число сбоев и скорость поставки. Единой метрики нет, поэтому используют набор показателей из кода, процессов и эксплуатации.

Метрика	Что показывает	Чем мерить
Коэффициент техдолга (SQALE)	Оценку времени на исправление найденных проблем относительно стоимости разработки кода	SonarQube и аналогичные платформы статического анализа
Покрытие тестами	Какая доля кода проверяется автоматически и насколько безопасен рефакторинг	Отчёты coverage в CI (PHPUnit, Jest, pytest и др.)
Цикломатическая сложность и дублирование	Насколько запутан код и сколько в нём копипаста	Статический анализ, линтеры
Возраст зависимостей и число CVE	Насколько устарели библиотеки и сколько в них известных уязвимостей	Dependabot, Renovate, аудит пакетных менеджеров
DORA-метрики	Lead time изменений, частоту релизов, change failure rate и время восстановления	Данные из Git, CI/CD и системы инцидентов
Доля спринта на исправления	Сколько времени команды уходит на баги и «пожары» вместо новых задач	Трекер задач (Jira, YouTrack) с метками типов работ
Регрессии на релиз	Как часто новые изменения ломают старую функциональность	Баг-трекер, отчёты QA

Автоматические метрики не видят всего: архитектурный долг и «зоны страха» лучше всего знает сама команда. Поэтому к цифрам полезно добавить регулярный опрос разработчиков — например, раз в квартал: какие части системы сильнее всего тормозят работу и сколько времени на них уходит. Такую практику используют и крупные компании, в том числе Google. Сравнение ответов от квартала к кварталу показывает, растёт долг или снижается.

Как управлять техническим долгом: пошаговый план

Управление техническим долгом — это постоянный процесс, в котором долг выявляют, оценивают, приоритизируют и гасят небольшими порциями параллельно с разработкой новых функций. Разовая «генеральная уборка» не работает: без изменения процессов долг вернётся за несколько месяцев. Вот план, по которому мы работаем с проектами клиентов:

1. Провести аудит кода и архитектуры. Прогнать статический анализ, проверить зависимости и тесты, опросить команду и составить реестр долга — список проблем с указанием места и последствий.
2. Завести бэклог техдолга. Каждый пункт реестра оформить задачей, в описании которой указаны «проценты»: что именно замедляется, на сколько часов и какие риски создаёт.
3. Приоритизировать. Разложить задачи по матрице «влияние на бизнес × стоимость исправления»; для точности подойдут методики WSJF или RICE. Уязвимости безопасности и проблемы производительности идут первыми.
4. Заложить постоянный бюджет. Выделять на погашение долга 15–20% ресурса каждого спринта. Популярный ориентир — правило 20% или модель 70/20/10, где 70% времени уходит на продукт, 20% — на долг и улучшения, 10% — на эксперименты.
5. Гасить инкрементно. Применять правило бойскаута («оставь код чище, чем он был»), рефакторить модули рядом с текущими фичами, а legacy-систему выводить по частям с помощью паттерна strangler fig.
6. Не допускать нового долга. Обязательный code review, линтеры и статический анализ в CI, Definition of Done с тестами и документацией.
7. Отслеживать метрики и показывать бизнесу динамику. Раз в месяц или квартал сверять показатели из раздела про измерение и показывать, как погашение долга ускоряет поставку и снижает число инцидентов.

Ключевой момент — шаг 4. Пока погашение долга зависит от того, «останется ли время», оно не случится никогда. Фиксированная доля спринта превращает рефакторинг из героизма в рутину, а бизнес получает предсказуемую скорость разработки.

Рефакторинг, переписывание или жить с долгом: что выбрать

Выбор стратегии работы с техническим долгом зависит от того, насколько долг мешает бизнесу, сколько ещё будет жить система и есть ли у команды ресурс на изменения. Универсального ответа нет, но есть четыре базовых подхода.

Подход	Когда подходит	Риски	Сроки и стоимость
Жить с долгом и мониторить	Модуль стабилен, почти не меняется или скоро будет выведен из эксплуатации	Долг может «выстрелить» при неожиданном изменении требований	Минимальные: только наблюдение и метрики
Инкрементный рефакторинг	Система в целом жизнеспособна, долг локален и мешает конкретным фичам	Низкие при наличии тестов; без тестов нужно сначала их написать	15–20% ресурса спринта постоянно, без остановки релизов
Модульная замена (strangler fig)	Ядро устарело, но переписать всё разом слишком рискованно	Период сосуществования старой и новой частей, сложность интеграции	Средние, растянуты во времени, окупаются по мере замены модулей
Полное переписывание	Технология мертва, архитектура не соответствует бизнесу, поддержка дороже новой разработки	Высокие: заморозка развития, потеря неочевидной логики, срыв сроков	Максимальные; бизнес долго платит за две системы

Полное переписывание — крайняя мера. Оно выглядит привлекательно («сделаем сразу правильно»), но на практике новая система часто повторяет ошибки старой и теряет годами накопленную бизнес-логику. Прежде чем принимать такое решение, стоит заказать независимый аудит кода и безопасности: он покажет, какая часть системы действительно безнадёжна, а какую можно спасти рефакторингом.

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

Как заказчику говорить о техдолге с подрядчиком

Разговор о техническом долге с подрядчиком — это способ понять, управляет ли команда качеством продукта или только выдаёт фичи. Заказчик не обязан разбираться в коде, но может задать вопросы, по ответам на которые сразу видно зрелость процессов:

• Как вы фиксируете технический долг и где его можно посмотреть?
• Какую долю спринта вы выделяете на погашение долга?
• Есть ли на проекте автотесты и CI, какое покрытие тестами?
• Как и как часто вы обновляете зависимости и фреймворк?
• Что будет с документацией и доступами, если проект перейдёт к другой команде?
• Какими метриками вы покажете, что долг уменьшается, а скорость растёт?

Главная ошибка заказчиков — требовать только новые функции и воспринимать рефакторинг как «работу ради работы». В краткосрочной перспективе это экономит деньги, а через год та же команда делает вдвое меньше за тот же бюджет. Хороший подрядчик сам поднимает тему долга, объясняет её в часах и деньгах и предлагает план. Если хотите независимо проверить состояние проекта, прочитайте, зачем нужен аудит кода и что в нём проверяют.

Как управляют техдолгом крупные компании

Крупные технологические компании управляют техническим долгом не отдельными проектами «по уборке», а встроенными в культуру правилами, которые делают долг видимым и заставляют команды за него отвечать. Три характерные практики:

• Amazon — «you build it, you run it». Команда, которая написала сервис, сама отвечает за его эксплуатацию. Проценты по долгу разработчики платят лично — ночными дежурствами и инцидентами, поэтому гасят его охотнее.
• Netflix — chaos engineering. Сбои в инфраструктуре создают намеренно, чтобы заранее найти хрупкие места. Скрытый архитектурный долг проявляется в контролируемых условиях, а не во время реальной аварии.
• Google — регулярные опросы инженеров. Компания системно спрашивает разработчиков, что мешает им работать, и использует ответы, чтобы находить и приоритизировать технический долг.

Масштаб у этих компаний другой, но принципы переносятся на проект любого размера: долг должен быть видимым, у него должен быть владелец, а время на погашение — заложено в план.

Частые вопросы о техническом долге

Технический долг — это плохо?

Нет, если долг взят осознанно и у команды есть план его погашения. Быстрое решение ради проверки гипотезы, запуска MVP или важного дедлайна — нормальный инструмент бизнеса. Плохо, когда долг никто не фиксирует и не возвращает: тогда проценты по нему постепенно съедают скорость разработки.

Чем технический долг отличается от багов?

Баг — это неверное поведение системы: что-то не работает или считается неправильно. Технический долг — это дорогая изменяемость: система работает, но любые изменения в ней занимают непропорционально много времени и часто ломают соседние части. Долг нередко становится источником багов, но это разные проблемы.

Сколько времени выделять на погашение техдолга?

Практический ориентир — 15–20% ресурса каждого спринта, например по правилу 20% или модели 70/20/10. Точная доля зависит от уровня долга: если проект в критическом состоянии, на время стоит выделить больше, а при низком долге хватит и 10%. Главное — чтобы доля была постоянной, а не «по остаточному принципу».

Можно ли полностью избавиться от технического долга?

Нет. Как отмечает Мартин Фаулер, разумно-неосознанный долг неизбежен: команда лучше понимает задачу в процессе работы, а технологии устаревают сами по себе. Цель не в нулевом долге, а в управляемом: он измерен, приоритизирован и не растёт быстрее, чем команда его гасит.

Как объяснить бизнесу необходимость рефакторинга?

Говорить на языке денег и сроков: сколько часов команда тратит на обход проблемного кода, насколько вырос срок выпуска функций, какие риски инцидентов и уязвимостей создаёт долг. Помогают внешние данные: по исследованию Stripe, на техдолг уходит около 33% времени разработчиков, а по оценке McKinsey он составляет 20–40% стоимости технологического ландшафта компании.

Какие инструменты помогают найти техдолг?

Платформы статического анализа вроде SonarQube, линтеры (ESLint, PHPStan и аналоги для других языков), сервисы контроля зависимостей Dependabot и Renovate, отчёты о покрытии тестами в CI. Архитектурный долг инструменты видят хуже, поэтому их дополняют ревью архитектуры и опросами команды.