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

Выявление технического долга начинается с определения того, где именно он находится. Кодовый долг проявляется в сложных функциях, дублировании, длинных классах, нарушении инкапсуляции и неочевидных зависимостях. Тестовый долг связан с отсутствием автоматических проверок, хрупкими тестами и невозможностью безопасно менять поведение системы. Архитектурный долг возникает, когда компоненты зависят друг от друга так, что локальное изменение запускает цепочку правок. Процессный долг появляется в ручных релизах, незафиксированных договорённостях и отсутствии понятного владельца компонента.

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

При этом статический анализ не равен полному измерению технического долга. В работах Lenarduzzi et al. [5] показано, что для части правил SonarQube связь с дефектами и изменениями статистически значима, но эффект невелик. Другие исследования указывают, что разные инструменты обнаружения долга часто не совпадают в результатах [11; 12]. Это означает, что предупреждение анализатора следует рассматривать как индикатор, а не как доказательство высокой стоимости сопровождения. Если правило сработало в редко изменяемом вспомогательном модуле, риск может быть ниже, чем в коде, который команда правит каждую неделю.

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

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

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

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

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

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

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

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

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

Литература:

1. ГОСТ Р ИСО/МЭК 25010–2015. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов. — М.: Стандартинформ, 2015.
2. Fowler M. Technical Debt. — 2019. — URL: https://martinfowler.com/bliki/TechnicalDebt.html.
3. Fowler M. Code Smell. — 2006. — URL: https://martinfowler.com/bliki/CodeSmell.html.
4. Lacerda G., Petrillo F., Pimenta M., Guéhéneuc Y.-G. Code Smells and Refactoring: A Tertiary Systematic Review of Challenges and Observations. — 2020. — URL: https://arxiv.org/abs/2004.10777.
5. Lenarduzzi V., Saarimäki N., Taibi D. Some SonarQube Issues have a Significant but Small Effect on Faults and Changes. A large-scale empirical study. — 2019. — URL: https://arxiv.org/abs/1908.11590.
6. Lenarduzzi V., Saarimäki N., Taibi D. The Technical Debt Dataset. — 2019. — URL: https://arxiv.org/abs/1908.00827.
7. Lenarduzzi V., Besker T., Taibi D., Martini A., Arcelli Fontana F. Technical Debt Prioritization: State of the Art. A Systematic Literature Review. — 2019. — URL: https://arxiv.org/abs/1904.12538.
8. Molnar A.-J., Motogna S. Longitudinal Evaluation of Open-Source Software Maintainability. — 2020. — URL: https://arxiv.org/abs/2003.00447.
9. Molnar A.-J., Motogna S. Long-Term Evaluation of Technical Debt in Open-Source Software. — 2020. — URL: https://arxiv.org/abs/2007.13422.
10. Li Y., Soliman M., Avgeriou P. Identification and Remediation of Self-Admitted Technical Debt in Issue Trackers. — 2020. — URL: https://arxiv.org/abs/2007.01568.
11. Lefever J., Cai Y., Cervantes H., Kazman R., Fang H. On the Lack of Consensus Among Technical Debt Detection Tools. — 2021. — URL: https://arxiv.org/abs/2103.04506.
12. Pfeiffer R.-H., Lungu M. Technical Debt and Maintainability: How do tools measure it? — 2022. — URL: https://arxiv.org/abs/2202.13464.
13. Nayebi M., Cai Y., Kazman R., Ruhe G., Feng Q., Carlson C., Chew F. A Longitudinal Study of Identifying and Paying Down Architectural Debt. — 2018. — URL: https://arxiv.org/abs/1811.12904.
14. Robredo M., Saarimaki N., Taibi D., Penaloza R., Lenarduzzi V. Evaluating Time-Dependent Methods and Seasonal Effects in Code Technical Debt Prediction. — 2024. — URL: https://arxiv.org/abs/2408.08095.