Технический долг
Технический долг (tech debt) — это цена, которую бизнес платит за быстрые, но компромиссные технические решения. Как финансовый долг: взяли «кредит», чтобы выпустить продукт быстрее, теперь платите «проценты» — замедление разработки, баги, сложность изменений.
Техдолг накапливается по-разному. Осознанный: «Сделаем хардкод сейчас, чтобы запустить MVP за неделю, потом перепишем». Неосознанный: разработчик не знал лучшего решения. Битовый: требования изменились, а архитектура осталась старой. Все три вида нормальны — вопрос в том, управляете ли вы долгом.
Признаки критического техдолга: новые функции занимают в 3-5 раз больше времени, чем раньше. Баги появляются в неожиданных местах после простых изменений. Новые разработчики неделями разбираются в коде. Деплой превращается в стресс для всей команды.
Нулевой техдолг — утопия и ненужная цель. Бизнесу важно выпускать продукты быстро. Но запущенный долг блокирует развитие. Золотое правило: выделять 20% времени разработки на рефакторинг и уменьшение долга.
Главное
- Цена за быстрые технические компромиссы
- Замедляет разработку новых функций со временем
- Бывает осознанным (MVP) и неосознанным (ошибки)
- 20% времени на уменьшение долга — золотое правило
- Нулевой долг не нужен — нужно управление долгом
Примеры
Стартап на MVP: захардкодили конфиг, скопировали код вместо абстракции — это нормально. Через год: добавить новый платёжный провайдер занимает месяц вместо дня, потому что логика оплаты размазана по 20 файлам. Легаси-система банка: новую функцию нельзя добавить без риска сломать старые — это критический техдолг.
Когда это нужно
Работать с техдолгом нужно, когда: скорость разработки упала в 2+ раза, каждое изменение порождает новые баги, команда боится трогать старый код, невозможно нанять разработчиков — все отказываются работать с легаси, бизнес хочет масштабироваться, а технологии не позволяют.
Связанные термины
Частые вопросы
Как измерить технический долг?
Прямых метрик нет, но есть косвенные: время на добавление новых фич (растёт?), количество багов после релиза (растёт?), время онбординга новых разработчиков. Инструменты статического анализа (SonarQube) показывают код-сигналы: дублирование, сложность, покрытие тестами.
Когда нужно переписывать систему с нуля?
Почти никогда. Полная переписка — это годы работы с непредсказуемым результатом. Лучше постепенный рефакторинг: заменяете модуль за модулем, не останавливая развитие продукта. Переписывать с нуля стоит, только если текущий стек принципиально не поддерживается (например, Flash).
Как объяснить техдолг заказчику?
Аналогия с ремонтом: вы можете клеить обои на кривые стены — быстро, но каждый следующий ремонт будет дороже. Или выровнять стены один раз — дольше сейчас, но проще потом. Покажите конкретику: «Эта задача занимает неделю вместо дня из-за техдолга».
Где это применяется
IT-консалтинг и цифровая стратегия
IT-консалтинг и аудит: карта IT-ландшафта с ценой каждой проблемы, выбор технологий и подрядчика, технический Due Diligence. Второе мнение по смете подрядчика — бесплатно за 48 часов, экспресс-аудит — от 260 000 ₽.
Как мы это делаемСвяжитесь с нами напрямую
Напишите или позвоните — ответим в течение рабочего дня и поможем разобраться с задачей.
- Telegram@marchcode — отвечаем быстрее всего
- WhatsAppсервис ограничен в РФ и может быть недоступен без дополнительных настроек
- +7 900 282 77 00позвоните — обсудим задачу голосом
- info@march-code.techопишите задачу письмом
Обращаясь к нам через мессенджер, почту или по телефону, вы по собственной инициативе передаёте контактные данные для подготовки ответа на ваше обращение (п. 5 ч. 1 ст. 6 152-ФЗ). Подробнее — в Политике конфиденциальности.
Продолжите изучение
