Представьте, что вы строите дом. Можно быстро построить его из доступных материалов, игнорируя некоторые строительные нормы, чтобы скорее въехать. Или можно делать всё по правилам, но это займёт больше времени. В первом случае вы "берёте в долг" – экономите время сейчас, но потом придётся исправлять недочёты, причём обычно с гораздо большими затратами.
То же самое происходит в разработке программного обеспечения. Каждый раз, когда команда выбирает быстрое временное решение вместо правильного, она берёт в долг у будущего. И как любой долг, технический долг имеет свои проценты – чем дольше его не отдавать, тем дороже обходится его обслуживание.
За 19 лет работы с различными проектами я выделил три верных признака того, что технический долг начинает тормозить бизнес:
Во-первых, разработка новых функций постоянно замедляется. То, что раньше занимало пару недель, растягивается на месяц или больше. Разработчики боятся трогать старый код, опасаясь сломать существующий функционал. А некоторые части системы становятся "священными" – к ним вообще никто не хочет прикасаться.
Во-вторых, адаптация новых разработчиков превращается в квест. Когда документация устарела, а код содержит самописные решения десятилетней давности, даже опытному разработчику требуется очень много времени, чтобы начать эффективно работать. Это существенно повышает стоимость найма и замедляет масштабирование команды.
В-третьих, каждый релиз становится лотереей. Вы исправляете одну проблему, но появляются две новые. Отсутствие или недостаточность автоматических тестов и современных инструментов разработки превращает каждое обновление в стрессовое событие для команды.
Здесь надо оговориться, что технический долг можно разделить на две категории: стратегический и случайный. В первом случае мы принимаем осознанное решение идти на компромиссы. Это может быть вызвано целью ускориться сейчас. Но также все должны понимать, что отложенная оптимизация должна состояться. Во втором же случае, тех долг может быть вызван неоптимальными решениями из-за недостатка опыта, недостатка вводных данных при проектировании архитектуры или несогласованности в командной работе.
По моему опыту, команды, которые активно работают над техническим долгом, в среднем более продуктивны. Однако, чтобы сосредоточиться на работе с тех долгом, надо сперва оценить масштаб работ.
Я бы предложил начать с простого — с простых вопросов команде: сколько времени занимает добавление типовой фичи? Насколько уверенно вы чувствуете себя при внесении изменений? Какие части системы вызывают больше всего проблем?
Дальше можно перейти к количественным метрикам: времени между релизами, количеству инцидентов, времени на исправление ошибок. А затем постараться внедрить современные инструменты позволяют измерить качество кода, его сложность, уровень тестового покрытия.
Работа с техническим долгом – это не разовая акция, а постоянный процесс. Я рекомендую начать с трёх шагов:
Первое – выделите ресурсы на технические улучшения. Классическое правило: 20% времени команды должно уходить на технический долг. Да, это может казаться дорого, но альтернатива обойдётся дороже.
Второе – внедрите культуру качества. Каждый новый код должен быть лучше старого. Код ревью, автоматические тесты, современные инструменты разработки должны стать стандартом, а не роскошью.
Третье – действуйте постепенно. Не пытайтесь переписать всё сразу. Начните с самых проблемных мест, которые больше всего тормозят развитие. Каждое улучшение должно приносить измеримую пользу бизнесу.
Технический долг – это не приговор, а естественная часть развития любого проекта. Важно научиться им управлять. Как показывает мой опыт работы с разными проектами, инвестиции в качество кода окупаются сторицей через ускорение разработки, стабильность системы и удовлетворённость команды.