Иногда разработчики принимают решения, которые ускоряют разработку в краткосрочной перспективе, но провоцируют дополнительные затраты в будущем. «Сейчас сделаем так, чтобы запуститься быстрее, а потом переделаем» — так и возникает технический долг. «Потом» может не наступить никогда, а вокруг неоптимального решения нарастает много новых сложностей и ошибок.

Представьте, что вы строили дом и решили сэкономить на фундаменте. Сначала вы выиграли в скорости и бюджете. Но теперь каждую новую пристройку приходится делать с оглядкой на слабое основание и, следовательно, тратить в разы больше времени, сил и денег.

В бизнес-проектах технический долг выглядит так:

• устаревший код, который понимает только один разработчик — тот, кто его и писал;
• отсутствие автоматизированных тестов, из-за чего любое изменение требует ручной проверки и может сломать работающий функционал;
• большое количество решений, нарушающих принципы хорошей архитектуры — временных «заплаток», сплетения функциональности разных модулей и других.

Результат — медленная разработка, которая влечёт за собой убытки для бизнеса: упущенные возможности для быстрого внедрения новых фич, растущие расходы на команду и повышенные риски сбоев.

Так, исследование Stripe и Harris Poll, проведенное в 2018 году, показало, что среднестатистический разработчик тратит 42% своего времени на решение технических проблем и проблем с поддержкой. Согласно данным, которые получили исследователи, общее количество рабочих часов программиста в неделю — около 41,1. Из них 17,3 часа уходит только на отладку плохого кода, который сложно поддерживать. То есть, вместо создания новых продуктов или улучшений, которые могли бы приносить доход, разработчики вынуждены исправлять старые. При этом около 3,8 часов в неделю тратится на написание плохого кода — костылей, заплаток. Stripe  подсчитали, что из-за этих нескольких часов глобальные потери ВВП могут достигать 85 миллионов долларов в год.

В конечном итоге накопившийся технический долг может привести к тому, что цена развития станет сопоставима с созданием нового сервиса.

Вам не нужно быть программистом, чтобы заметить проблему, достаточно обратить внимание на эти маркеры:

1. Снижение скорости выхода обновлений. Если раньше команда выпускала новую фичу за две недели, а теперь на ту же по сложности задачу уходит месяц, то это будет главным индикатором роста долга.
2. Увеличивающееся количество багов. Например, если после обновления ломается то, что работало раньше, а команда разработки постоянно «тушит пожары» вместо создания новых фич для вашего продукта.
3. Сложность онбординга новых разработчиков. Если специалисту требуется несколько месяцев, чтобы начать эффективно работать с кодом вашего сервиса, то это говорит о плохой документации и сложной архитектуре.

Если эти симптомы вам знакомы, ваш проект уже терпит убытки. 

Просто «все переписать» — далеко не всегда эффективное вложение денег. Чтобы избавиться от технического долга, нужно выстроить систему управления им, как любым другим активом или обязательством компании.

Первый шаг — понять масштаб проблемы. Провести аудит кода и архитектуры, чтобы понять, какие проблемы являются критическими и тормозят развитие, а какие можно пока отложить. Результатом станет дорожная карта с приоритетами и оценкой трудозатрат.

Дальше — плановое «погашение» долга в каждом спринте. Например, хорошей практикой считается выделение 20% времени в каждой итерации разработки на рефакторинг — улучшение качества кода, написание тестов и улучшение инфраструктуры. Как правило, это предотвращает накопление новых долгов.

Также, чтобы долг не рос, нужна профилактика. Например, в нашей компании это:

• регулярное code review от более опытных коллег для поддержания качества;
• автоматическое тестирование для минимизации рисков;
• внедрение принципов чистой архитектуры с первых этапов разработки.

Справиться с некачественным кодом помогает рефакторинг. Если говорить простым языком, рефакторинг — это «возвращение» технического долга, а также профилактика его быстрого накопления. Он улучшает внутреннюю структуру кода без изменения его внешнего поведения.

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

Рефакторинг — эффективный инструмент управления долгом, а не разовая «уборка». Вот как он работает на практике:

• Ускоряет онбординг новых специалистов. Код становится легко понять и изменить новому разработчику. Рефакторинг помогает убрать «мусор»: дублирование, непонятные названия переменных и функций, излишне сложные логические цепочки.
• Упрощает добавление нового функционала. Когда код чистый и структурированный, добавление новой фичи перестает быть квестом с непредсказуемым результатом. Разработчик не тратит часы на то, чтобы разобраться в старом коде и понять, как его изменение повлияет на другие части системы. Вместо этого он четко видит, куда и как нужно интегрировать новую функциональность. Это ускоряет вывод обновлений на рынок.
• Снижает количество ошибок. Сложный и запутанный код — рассадник багов. Внесение даже небольшого изменения в таком коде может неожиданно сломать другую, казалось бы, несвязанную функцию. Рефакторинг упрощает логику и делает поведение программы более предсказуемым. Кроме того, процесс рефакторинга часто включает в себя покрытие кода автоматическими тестами, которые не дают ошибкам попасть в рабочую версию продукта.

Рефакторинг окупается за счет снижения будущих затрат на разработку, увеличения скорости запуска новых функций и повышения стабильности вашего продукта. Регулярное проведение рефакторинга позволяет планомерно предотвращать накопление технического долга, а не бороться с его последствиями.

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

Но это не значит, что стоит всеми силами стремиться к тому, чтобы держать технический долг на нуле. В бизнесе большое количество долгов действительно может потопить компанию, но кредиты могут позволить совершить экономический рывок тогда, когда это нужно. Поэтому главное в работе с техническим долгом — его осознание и понимание его объемов. Тогда можно осознанно «залезть» в технические долги, когда нужно крайне быстро выпустить новую функциональность, а потом, в спокойной обстановке, рефакторингом «вернуть» этот долг.