Технический долг

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

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

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

Смежные термины

• РефакторингРефакторинг — изменение внутренней структуры кода без изменения его внешнего поведения: функциональность до и после одинакова, меняются читаемость, связанность и стоимость следующей доработки, а результат подтверждается тестами и регрессом.
• Легаси-кодЛегаси-код — работающий код, который дорого менять: он написан на устаревшем стеке, не покрыт тестами или потерял авторов, поэтому любая правка требует восстанавливать логику по исходникам и грозит поломкой в непредсказуемом месте.
• CI/CDCI/CD — конвейер, который на каждый коммит автоматически собирает проект, прогоняет тесты и проверки, а затем выкладывает прошедшую сборку на тестовый стенд или в продакшн, убирая ручной деплой вместе с человеческим фактором.
• Продуктовый бэклогПродуктовый бэклог — упорядоченный по приоритету список всего, что может быть сделано в продукте: он не является планом с датами, постоянно пересматривается, и за порядок в нём отвечает один человек — владелец продукта.
• МонолитМонолит — приложение, которое собирается и разворачивается одним куском: весь код лежит в общем репозитории и выполняется в одном процессе, работает с одной базой и выкатывается целиком, что даёт простоту разработки ценой связанности.

Услуги по теме

• Доработка и поддержка сайтаНе каждый проект нужно переписывать. Часто дешевле починить скорость, исправить технические SEO-ошибки, добавить недостающие разделы и интеграции — и получить рабочий сайт без бюджета на новую разработку.
• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.

Почитать подробнее

• Редизайн сайта без потери трафика: этапы, риски и SEO-чеклист переездаПоловина запросов на редизайн — это на самом деле проблемы контента, скорости или оффера. Разбираем, как отличить одно от другого, почему поэтапный вывод безопаснее большого запуска и что должно быть в чеклисте переезда, чтобы не потерять органику.
• Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.