Технический долг — самая недооценённая статья расходов в веб-разработке. На старте проекта он невидим: сайт работает, заказы идут, всё выглядит нормально. Но каждое «сделаем быстро, потом поправим» — это кредит, который бизнес выплачивает процентами: замедлением разработки, багами, уязвимостями и растущими счетами от подрядчиков. В этой статье разберём, откуда берётся технический долг, как посчитать его реальную стоимость в часах и рублях и по каким признакам понять, что проекту нужен рефакторинг, а не очередная заплатка.
Что такое технический долг простыми словами
Представьте, что вы построили склад за месяц, потому что товар уже ехал, а места для него не было. Крыша течёт, стеллажи кривые, но работать можно. Через год вы надстраиваете второй этаж — на те же кривые стеллажи. Через два — третий. Каждый новый этаж обходится дороже, потому что приходится сначала укреплять старые конструкции. Технический долг — это код, написанный «на быстро» без архитектуры, тестов и документации. Как любой кредит, он имеет тело (объём проблемного кода) и проценты (дополнительные часы на каждую новую задачу). Отличие в том, что проценты растут со временем: чем дольше живёт проблемный код, тем дороже его трогать.Откуда берётся долг: пять типичных сценариев
В большинстве случаев долг копится не из-за «плохих программистов», а из-за бизнес-решений. Вот самые частые источники:- Спринт на запуск. Нужно было «вчера»: релиз без тестов, жёстко зашитые настройки, костыли вместо интеграций.
- Смена подрядчика или разработчика. Документации нет, логика «только в голове у бывшего сотрудника», новый специалист месяц разгребает чужой код.
- «Временные» решения. Заплатка, которую обещали убрать через месяц, живёт в проекте пять лет и обросла зависимостями.
- Устаревший стек. CMS, плагины и библиотеки не обновлялись годами — каждая попытка апгрейда рискует уронить сайт.
- Фичи без плана. Функциональность наращивалась слоями без рефакторинга, пока код не превратился в лабиринт.
Во сколько обходится долг: считаем в часах и рублях
По отраслевым исследованиям, в проектах с большим долгом разработчики тратят 25–40% времени не на развитие, а на борьбу с последствиями прошлых решений. Это значит, что из бюджета в 500 000 ₽ на доработки около 150 000 ₽ уходит «в никуда». Конкретный пример: интеграция с платёжным шлюзом на чистой архитектуре занимает 40 часов. Тот же функционал на проекте с трёхлетним legacy — 100–120 часов, потому что сначала нужно распутать существующий код. Плюс скрытые проценты: долгая загрузка страниц режет конверсию и SEO, уязвимости оборачиваются инцидентами безопасности, а простой интернет-магазина в высокий сезон — прямыми потерями выручки.Тревожные признаки: аудит нужен уже сейчас
Технический долон редко проявляется внезапно — он наращивает обороты постепенно. Проверьте свой проект по этому чек-листу:- Каждое обновление сайта ломает что-то, что раньше работало.
- Оценка новой задачи от подрядчика стабильно выше ожидаемой — «потому что там всё завязано».
- Никто в команде не может быстро объяснить, как работает ключевая часть системы.
- Сайт медленно грузится, а оптимизация не даёт результата — всё упирается в архитектуру.
- Админка пугает: менеджеры боятся нажать «не туда».
- Стек и зависимости не обновлялись больше года.
Рефакторинг или переписывание: как выбрать
Главный миф: «если код плохой — надо всё переписать с нуля». На практике полная переработка — самый дорогой и рискованный путь: вы на месяцы замираете в развитии и теряете работающую бизнес-логику, накопленную годами. Рефакторинг оправдан, когда бизнес-логика работает, но код стал медленным и запутанным. Переписывание имеет смысл, если платформа мертва (нет обновлений и специалистов), архитектура фундаментально не тянет нагрузку или смена курса делает старую систему ненужной. Рабочая стратегия для большинства проектов — правило Парето: примерно 20% кода генерируют 80% проблем. Рефакторинг этих «горячих точек» — каталог, корзина, платёжные модули — даёт основной эффект за 15–20% стоимости исходной разработки.Как рефакторить, не останавливая продажи
Рефакторинг — не «большой взрыв», а последовательный процесс. Проверенная схема:- Аудит. Команда инвентаризирует код: где костыли, где риски, что блокирует развитие. Итог — карта долга с приоритетами.
- Тесты до правок. Автотесты на критичные сценарии (заказ, оплата, регистрация) — страховка, что рефакторинг не сломает работающее.
- Рефакторинг по частям. Небольшие итерации по 1–2 недели с релизами на боевой сервер. Никаких «три месяца тишины, потом всё новое».
- Заморозка на время работ. Новые фичи не пишутся поверх проблемных модулей, пока те переделываются.
- Метрики. Скорость страниц, время разработки задач, количество инцидентов — до и после, чтобы видеть отдачу вложений.
Как не копить долг заново
Рефакторинг без изменения процессов вернёт вас в исходную точку за год-полтора. Закрепите профилактику на уровне договора и регламентов: резервируйте 15–20% бюджета разработки на поддержку и улучшение кода. Это звучит как расход, но по факту это обслуживание кредита — всегда дешевле, чем проценты. Что ещё работает: код-ревью всех изменений, обновление зависимостей минимум раз в квартал, обязательная документация при смене подрядчика и правило «не оставляем заплатку без задачи на переделку». И главное — прививайте культуру команде: «временное» решение, которое прожило больше месяца, перестаёт быть временным.Технический долг — это не приговор, а управляемый финансовый инструмент. Взять его в момент запуска — нормально и часто оправданно: скорость выхода на рынок важнее идеального кода. Опасно не само наличие долга, а его неконтролируемый рост, когда проценты съедают бюджет развития, а каждый релиз становится лотереей. Простая дисциплина решает проблему: аудит раз в год, регулярный бюджет на поддержку, рефакторинг горячих точек до того, как они заблокируют развитие. Если узнали свой проект в признаках из этой статьи — начните с аудита: за несколько дней вы получите карту долга и поймёте, что чинить в первую очередь и во сколько это обойдётся.