Технический долг в разработке: что это такое, чем опасен и как его погасить

Любые доработки сайта занимают всё больше времени? Новые функции ломают старые? Подрядчик постоянно увеличивает оценки задач, а разработчики всё чаще говорят про ограничения системы?

Скорее всего, проект накопил технический долг.

Технический долг — одна из главных причин, по которой развитие сайта, интернет-магазина, личного кабинета или веб-сервиса становится дорогим, медленным и рискованным. При этом сам по себе технический долг не является катастрофой. Более того, в определённых ситуациях он помогает бизнесу быстрее запускать новые продукты, тестировать гипотезы и выходить на рынок раньше конкурентов.

Проблемы начинаются тогда, когда долг копится годами и никто не занимается его погашением.

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

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

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

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

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

Так появляется технический долг.

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

Сначала кажется, что жить можно. Но со временем количество временных решений растёт. Удлинители подключаются к удлинителям, розетки перегружаются, а любое изменение требует всё больше времени и денег. В какой-то момент становится понятно, что косметическим ремонтом уже не обойтись — нужен капитальный.

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

Поэтому технический долг — это не плохой код. Это накопленные последствия прошлых компромиссов.

Технический долг редко появляется внезапно. Обычно система долго подаёт сигналы о том, что её пора приводить в порядок. Часть этих сигналов видят разработчики. Часть замечает сам бизнес.

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

Признаки в работе сайта или сервиса:

• небольшие изменения требуют непропорционально много времени;
• сроки разработки становятся всё менее предсказуемыми;
• после исправления одного бага появляются новые ошибки;
• релизы проходят с повышенным уровнем стресса;
• производительность системы постепенно снижается;
• пользователи начинают чаще сталкиваться со сбоями.

Признаки в коде и архитектуре:

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

Признаки в работе команды:

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

Сам по себе один признак ещё не говорит о серьёзных проблемах.

Но если подобных сигналов становится много, стоимость поддержки проекта начинает расти быстрее его бизнес-ценности.

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

На практике технический аудит нужен гораздо раньше.

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

Технический аудит стоит провести, если:

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

Главная задача аудита — не найти виноватых и не доказать, что код плохой.

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

После качественного аудита бизнес получает ответы на вопросы:

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

Именно поэтому технический аудит сайта или веб-сервиса часто становится первым этапом работы с легаси-проектами.

Разработчики обычно говорят о техническом долге через код, архитектуру и технологии.

Для бизнеса всё гораздо проще. Технический долг почти всегда превращается в деньги. Причём не только в прямые расходы на разработку, но и в упущенные возможности.

Удорожание разработки

Первое и самое очевидное последствие.

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

Снижение скорости выхода на рынок

Современный рынок требует быстрых изменений.

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

Рост рисков безопасности

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

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

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

Зависимость от отдельных специалистов

Один из самых недооценённых рисков.

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

Потеря конкурентоспособности

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