Технический долг
Технический долг (tech debt) — это цена, которую бизнес платит за быстрые, но компромиссные технические решения. Как финансовый долг: взяли «кредит», чтобы выпустить продукт быстрее, теперь платите «проценты» — замедление разработки, баги, сложность изменений.
Техдолг накапливается по-разному. Осознанный: «Сделаем хардкод сейчас, чтобы запустить MVP за неделю, потом перепишем». Неосознанный: разработчик не знал лучшего решения. Битовый: требования изменились, а архитектура осталась старой. Все три вида нормальны — вопрос в том, управляете ли вы долгом.
Признаки критического техдолга: новые функции занимают в 3-5 раз больше времени, чем раньше. Баги появляются в неожиданных местах после простых изменений. Новые разработчики неделями разбираются в коде. Деплой превращается в стресс для всей команды.
Нулевой техдолг — утопия и ненужная цель. Бизнесу важно выпускать продукты быстро. Но запущенный долг блокирует развитие. Золотое правило: выделять 20% времени разработки на рефакторинг и уменьшение долга.
Ключевые преимущества
- Цена за быстрые технические компромиссы
- Замедляет разработку новых функций со временем
- Бывает осознанным (MVP) и неосознанным (ошибки)
- 20% времени на уменьшение долга — золотое правило
- Нулевой долг не нужен — нужно управление долгом
Примеры
Стартап на MVP: захардкодили конфиг, скопировали код вместо абстракции — это нормально. Через год: добавить новый платёжный провайдер занимает месяц вместо дня, потому что логика оплаты размазана по 20 файлам. Легаси-система банка: новую функцию нельзя добавить без риска сломать старые — это критический техдолг.
Когда это нужно
Работать с техдолгом нужно, когда: скорость разработки упала в 2+ раза, каждое изменение порождает новые баги, команда боится трогать старый код, невозможно нанять разработчиков — все отказываются работать с легаси, бизнес хочет масштабироваться, а технологии не позволяют.
Связанные термины
Частые вопросы
Как измерить технический долг?
Прямых метрик нет, но есть косвенные: время на добавление новых фич (растёт?), количество багов после релиза (растёт?), время онбординга новых разработчиков. Инструменты статического анализа (SonarQube) показывают код-сигналы: дублирование, сложность, покрытие тестами.
Когда нужно переписывать систему с нуля?
Почти никогда. Полная переписка — это годы работы с непредсказуемым результатом. Лучше постепенный рефакторинг: заменяете модуль за модулем, не останавливая развитие продукта. Переписывать с нуля стоит, только если текущий стек принципиально не поддерживается (например, Flash).
Как объяснить техдолг заказчику?
Аналогия с ремонтом: вы можете клеить обои на кривые стены — быстро, но каждый следующий ремонт будет дороже. Или выровнять стены один раз — дольше сейчас, но проще потом. Покажите конкретику: «Эта задача занимает неделю вместо дня из-за техдолга».
Где это применяется
Техническая поддержка и сопровождение
Техническая поддержка сайта и ПО на подписке: дежурство по SLA, реакция на инциденты, багфиксы, обновления зависимостей и закрытые CVE, 10–40 часов доработок в месяц. Берём и чужой код — после аудита, даже если подрядчик пропал и документации нет. Standard — от 130 000 ₽/мес, типичный тариф работающего продукта — 325 000 ₽/мес с 20 часами. Аудит состояния проекта — бесплатно за 3–5 дней, до договора.
Как мы это делаемПродолжите изучение
