Техдолг приносит бизнесу (а нередко и самим айтишникам) ощутимые потери. Например, по данным McKinsey, он отъедает порядка 40% ИТ-бюджета. И время тоже — по оценкам исследования CAST, уровень глобального техдолг вырос настолько, что суммарное время на его исправление оценивается в 61 млрд рабочих дней — и это еще довольно консервативная цифра.
Однако техдолг — это не всегда про TODO в комментариях и паутинку из костылей. Да и вообще не всегда про код — внушительная его часть появляется еще до написания первой строки. В этой статье разберемся, что это за зверь такой, можно ли с ним разобраться или хотя бы укротить. Погнали!
Что такое техдолг на самом деле
Что приходит вам на ум при слове «техдолг»? Возможно, спагетти-код, забытые комменты, копипаста не пойми откуда и «временные» решения. Логично — код мы видим каждый день, с ним работаем, его рефакторим.
А теперь узнаем, что на эту тему говорят данные.
Исследователи InsighTD опросили 653 разработчика из 6 стран, чтобы понять реальную структуру техдолга. Вот как, по результатам их опроса, распределяются типы долга:
Тип техдолга | Доля |
Design debt | 22% |
Test debt | 20% |
Code debt | 14.7% |
Architecture debt | 10.7% |
Documentation debt | 9% |
Код — это лишь 14.7% проблемы. Все остальное — долг проектирования, тестирования, архитектурный, долг документации — могло появиться еще до того, как была написана первая строка кода.
«We identified the top 5 TD types by occurrence as: design debt (21.99%), test debt (19.94%), code debt (14.66%), architecture debt (10.7%), and documentation debt (9.09%)» — InsighTD Survey, ScienceDirect
Иными словами – когда команда собирается разобраться с техдолгом и начинает с рефакторинга кода, она работает меньшей чем шестой частью проблемы. Остальное заложено в архитектуре, тестах, документации (или ее отсутствии), в решениях, принятых на этапе проектирования.
То, что нельзя переписать за выходные
Есть принципиальная разница между техдолгом в коде и техдолгом в архитектуре. Код можно переписать относительно оперативно. А вот с архитектурой такой фокус не пройдет.
Долг проектирования и архитектурный долг — это последствия решений, принятых на дейлике или на бумаге, в голове архитектора или тимлида еще до того, как был открыт редактор кода. Это мог быть выбор между монолитом и микросервисами, между синхронным и асинхронным взаимодействием, между собственной реализацией и сторонним сервисом. И если выбор был неудачным — никаким рефакторингом это не лечится.
Вот парочка хрестоматийный кейсов:
Southwest Airlines
В декабре 2022 года, в разгар праздничного сезона, Southwest Airlines столкнулась с коллапсом: более 16 000 отмененных рейсов и десятки тысяч застрявших пассажиров. Причиной стала устаревшая система планирования экипажей SkySolver, разработанная еще в 1990-х годах и ни разу не модернизированная для работы с пиковыми нагрузками.
Когда зимний шторм Elliott вызвал массовые сбои в расписании, система просто не справилась с объемом переназначений экипажей и упала. Архитектурный долг, копившийся десятилетиями, превратился в $600 млн возвратов пассажирам и $140 млн штрафов — почти $1 млрд прямых убытков, не считая репутационного ущерба.
Siri
Apple запустила Siri в 2011 году — первой среди мейнстрим-голосовых ассистентов, за годы до Alexa и Google Assistant. К 2024 году Siri должна была быть самым продвинутым AI-ассистентом на планете. Вместо этого она стала одним из самых показательных примеров архитектурного долга в современной технологии.
Внутренние отчеты описывали Siri как технически фрагментированную систему: старые rule-based компоненты, сшитые с новыми генеративными моделями. Такая лоскутная архитектура делала обновления сложными и приводила к постоянным ошибкам — внутреннее тестирование показало, что ключевые функции Siri работают в 66-80% случаев.
За один год Apple покинули 12-15 ключевых AI-исследователей и руководителей, включая главу команды AI-моделей. В 2024 Apple анонсировала «персонализированную Siri» с впечатляющими новыми функциями, но так и не выпустила ее. Релиз откладывали повторно, и в марте 2025 Apple публично признала, что работа занимает больше времени, чем ожидалось.
В январе 2026 Apple завершила сделку по выплате Google примерно $1 млрд в год за лицензирование кастомной модели Gemini с 1.2 триллиона параметров и перестройку основной функциональности Siri на ее базе. Как сообщается, архитектура Siri была настолько запутанной, что ее пришлось полностью перестроить с нуля на базе большой языковой модели. Самая дорогая компания в мире обратилась к прямому конкуренту за помощью с одним из своих флагманских продуктов — потому что накопленный архитектурный долг сделал невозможным достаточно быструю модернизацию Siri собственными силами.
В этом и заключается природа архитектурного долга — проблема не в том, как написан код, а в том, какую систему этот код обслуживает.
Как может проявляться архитектурный долг?
Монолит, который давно пора разделить — он разросся настолько, что одна команда уже не может в нем разобраться, но декомпозиция на сервисы все откладывается.
Неверно выстроенные границы — из-за этого данные ходят через лишних посредников, а никак не связанные друг с другом фичи приходится выкатывать в продакшен одним релизом.
Запутанная система событий — сеть очередей и подписок, где уже никто не может проследить полный путь сообщения от начала до конца.
И такие штуки, как правило, копятся с самого первого спринта, с первого решения «давайте пока сделаем побыстрее, потом переделаем». Только «потом» не наступает — потому что на повестке всегда стоят новые фичи.
Реальные потери
CodeScene провела исследование, которое дает, довольно неприятную цифру по техдолгу. Как оказалось, разработчики тратят до 42% своего рабочего времени на работу с последствиями техдолга — не на написание нового кода, а на разбор и починку того, что уже есть.
«Technical debt wastes up to 42% of developer time. By identifying and managing high-impact technical debt, organizations can reclaim lost capacity and deliver faster with existing teams.» — CodeScene Research.
Вдумайтесь. Почти половина рабочего дня уходит не на создание ценности, а на обслуживание прошлого.
Но есть и обратная сторона медали. Те же данные CodeScene показывают, что дает «здоровый» код:
2× быстрее разработка — фичи доезжают до продакшена вдвое быстрее
15× меньше дефектов — баги не плодятся лавиною после каждого релиза
9× предсказуемее доставка — оценки перестают быть гаданием на кофейной гуще
«Healthy code delivers 2× faster development, 15× fewer defects, and 9× more predictable delivery» — CodeScene Research.
Иными словами, разница между «здоровым» и «нездоровым» кодом — это далеко не 10-20% производительности.
Почему техдолг вообще копится
Иногда можно встретить мнение, что в появлении техдолга виноваты джуны, поверхностные код-ревью или даже просто лень. Мол, если бы все писали «правильно», долга бы не было.
Давайте посмотрим, что говорят исследования.
В масштабном опросе InsighTD разработчиков прямо спросили, откуда берется долг. По их мнению, основным источником техдолга является… дедлайн.
«Time pressure or deadlinewas the single most cited cause of TD» — InsighTD Survey
И работает это примерно так:
Бизнесу нужно «вчера», чтобы обогнать конкурентов или закрыть квартал.
Команда идет на осознанный компромисс и берет краткосрочное, но далеко не самое оптимальное решение.
Быстрые фиксы накапливаются и выливаются в техдолг, который в итоге ложится на плечи тех же разработчиков, только позже, например, через год.
Как формулируют аналитики CAST, техдолг возникает, когда скорость приоритетнее качества). Получается, что техдолг — это не техническая проблема, а экономическая. Это как кредит, который бизнес берет у разработки под высокий процент. И пока мы обсуждаем его в терминологии «плохого кода», мы говорим с бизнесом на разных языках.
Как измерять?
Казалось бы, логичный следующий шаг — внедрить метрику техдолга, начать ее измерять и управлять. Однако в обзоре практик управления техдолгом можно найти вот такие интересные выводы, сделанные в том числе на основе опыта Google. Исследователи проанализировали 117 метрик как индикаторов распространенных областей техдолга — зависимости, качество кода, деградация и другие.
И пришли к выводу, что ни одна метрика не отражает тот техдолг, о котором сообщают сами разработчики. Это не значит, что мерить не нужно. Это значит, что нужно мерить свою метрику — ту, которая отражает именно ваши боли.
Как это можно сделать?
1. Контекстные метрики
Спросите себя — что именно болит в ваше случае больше всего? Для одной команды это время онбординга нового разработчика. Для другой — частота инцидентов в продакшене. Для третьей — процент отмененных релизов из-за регрессии.
В этом обзоре приводится таблица инструментов с формулами расчета индекса долга. Каждый из них считает по-своему, и эти цифры не сравнимы между собой.
2. Приоритизация по бизнес-ценности
Не весь техдолг стоит гасить. Есть долг, который просто лежит и не мешает — трогать его нет смысла. Есть долг, который тормозит разработку, но не влияет на бизнес — это вопрос баланса. А есть долг, который убивает процессы — его нужно гасить в первую очередь.
Вот, например, McKinsey предлагает фреймворк из трех ступеней:
insights edge — понимание, где долг бьет сильнее всего;
commitment edge — готовность бизнеса выделить ресурсы;
execution edge — способность команды выполнить поставленные задачи.
Если говорить проще — сначала нужно определить, где долг бьет больше всего, потом убедить бизнес выделить ресурсы, и только после этого гасить.
А боритесь ли с техдолгом вы? Поделитесь в комментариях, что работает, а что нет, и имеет ли вообще смысл его укрощать. Будем ждать ваших историй!
