Введение
Технический долг (техдолг, technical debt) – метафора, введённая Уордом Каннингемом в начале 1990-х годов. Подобно финансовому долгу, технический долг позволяет «взять взаймы» у будущего: принять быстрое, но не лучшее техническое решение сейчас, чтобы успеть к дедлайну. Расплата – «проценты» в виде снижения скорости разработки, роста числа багов и сложности поддержки системы.
Каннингем описал это так: «Не совсем правильный код, который мы когда-нибудь исправим». Не всякий техдолг является ошибкой – иногда сознательный техдолг оправдан для быстрого вывода продукта на рынок.
История и контекст
Уорд Каннингем впервые использовал метафору долга в 1992 году для объяснения менеджерам необходимости рефакторинга. Мартин Фаулер развил концепцию, предложив «квадрант технического долга» по осям «осознанный/неосознанный» и «благоразумный/безрассудный». Agile Alliance включила управление техдолгом в число ключевых инженерных практик XP и современного Agile.
Как это работает
Виды технического долга:
- Долг по коду – спагетти-код, дублирование, отсутствие тестов, нарушение SOLID;
- Архитектурный долг – тесная связанность (coupling), монолит вместо микросервисов, неверный выбор БД;
- Технологический долг – устаревшие библиотеки, deprecated API, legacy-фреймворки;
- Инфраструктурный долг – ручные деплои, отсутствие IaC, непропатченные серверы;
- Долг по тестированию – недостаточное покрытие, нет интеграционных тестов, нет CI.
Управление техдолгом включает его выявление (code review, статический анализ – SonarQube, Checkstyle), оценку в условных «долговых единицах» и включение задач по рефакторингу в бэклог наравне с новым функционалом.
Где применяется
- Любая команда разработки – мониторинг состояния кодовой базы через инструменты статического анализа;
- Legacy-системы при миграции – выявление и поэтапная ликвидация накопленного долга;
- Agile-процессы – выделение 20% спринта на технические задачи;
- M&A и due diligence – оценка техдолга при покупке технологического продукта.
Преимущества управления и ограничения
Зачем управлять техдолгом: снижение скорости разработки («interest»); рост числа регрессионных багов; сложность онбординга новых разработчиков; риски безопасности из-за устаревших зависимостей.
Ограничения: нулевой техдолг недостижим и нецелесообразен; некоторые решения становятся техдолгом только ретроспективно; избыточный рефакторинг «ради чистоты» без бизнес-ценности – waste.
Связь с другими понятиями
Техдолг особенно опасен в монолитных архитектурах из-за высокой связанности. Переход к микросервисам – один из способов ликвидировать архитектурный долг, но сам создаёт операционный долг. CI/CD и автоматические тесты – основные инструменты контроля техдолга. Feature Flag может стать источником техдолга (flag debt), если флаги не удаляются вовремя. Domain-Driven Design помогает избежать накопления архитектурного долга с самого начала.
