Как выбраться из технического долга

Многие программисты, особенно неопытные, допускают ошибки или применяют не оптимальные решения. Часто это вынужденная мера – компромисс между качеством и скоростью релиза. Так растёт ком проблем: недоделанные функции, неоптимальные алгоритмы, спорные архитектурные моменты и другие костыли. Это и есть технический долг – все недочёты, которые накопились в коде и ждут своего решения.

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

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

В большинстве случаев всё из-за недостатка времени. Например, есть некий стартап. Инвесторы вкладывают в него деньги и хотят побыстрее выйти на рынок: обогнать конкурентов, получить прибыль. Оговариваются сроки разработки, и команда стартапа должна справиться до дедлайна. Времени не хватает, приходится «срезать углы»: откладывать какие-то задачи на потом, упрощать тестирование (некоторые места вообще не проверять), составлять только базовую документацию и т.д. Продукт выйдет быстрее, но за счёт ухудшения качества. Если его не наверстать, то груз проблем усложнит разработку.

Есть и другие причины:

• Неправильная архитектура проекта.
• Недостаток опыта и знаний у программистов.
• Отсутствие чётких стандартов разработки. Каждый делает как хочет, и на выходе получаем неоптимальный результат.
• Отсутствие документации. Без регламента программист может неправильно представлять работу системы.
• Недостаточная автоматизация разработки, тестирования, развёртывания. Ручные операции отнимают больше времени и чаще приводят к ошибкам.
• Недостаточное тестирование.
• Откладывание рефакторинга.
• Использование устаревших библиотек, фреймворков.
• Применение инструментов без саппорта. Они часто появляются при разработке аутсорс-проектов. Компания создаёт «внутренние библиотеки», но не сопровождает их официальной поддержкой. Такие продукты — это потенциальные источники ТД.
• Дефицит ресурсов. Не хватает людей, бюджета, инструментов.
• Плохо организованный коллектив. Нет взаимодействия между разными командами, отсутствует менторство.

Его определяют по ряду признаков:

• Архитектура проекта не выдерживает нагрузок или заданных требований.
• Низкая степень модульности компонентов. Большой, неделимый код сложнее понимать и поддерживать.
• Много пометок TODO и FIXME.
• Часто изменяемые участки кода. Скорее всего, они проблемные.
• Низкокачественный код отдельных компонентов.
• Костыли вместо полноценных решений.
• Низкое или нулевое покрытие тестами.
• Невысокая производительность.
• Недостаточная масштабируемость.
• Наличие уязвимостей.

Неполная или отсутствующая документация кода, архитектуры.

Чем больше «хлама», тем труднее с ним управиться. Мы можем взять это бремя на себя и разобраться с тем, что уже накопилось у вас на проекте. Наша команда проанализирует код: что в нём не так и почему. Мы оценим приоритетность каждой проблемы, составим план работы и уберём до 80% вашего техдолга.
Эту задачу можно выполнить только при комплексном подходе. «Уборка» требует определённых расчётов, действий и работы с людьми.

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

Второе – спланировать действия:

1. Составить бэклог задач по техническому долгу.
2. Рассортировать задачи по приоритетности (степени важности и сложности выполнения). Для этого можно использовать Матрицу Эйзенхауэра, фреймворк RICE. Сначала нужно браться за то, что требует немедленного внимания.
3. Рассчитать, хватит ли ресурсов на каждую задачу. Возможно, потребуется больше сотрудников или временное перераспределение тасков.
4. Установить сроки выполнения.
5. Распределить задания между разработчиками.

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

Четвёртое – выполнять задачи по беклогу. Самый продуктивный метод – закладывать некоторое время от разработки только на технический долг. Можно посвящать 10-30% от очередной итерации или целую итерацию (между проектами), или день в одну-две недели. Крупные компании, которые не справляются с техдолгом, выделяют на него целые группы разработчиков или передают на аутсорс – например, нам.

Командные усилия – это единственный выход из технического долга. Нужно объяснять программистам, какие проблемы скопились на проекте, к чему они приведут: ошибкам, нестабильности, замедлению скорости разработки. Следует показывать реальные примеры того, как устранение ТД экономит время, силы и ресурсы. Осведомлённые мотивированные люди справятся лучше тех, кто не заинтересован и не понимает, что происходит.

Другая сторона – это владельцы продукта. «Бизнес» думает категориями рынка, поэтому с ними лучше говорить о финансовых рисках. Растущий техдолг ухудшает качество продукта, тормозит выход новой версии, отталкивает пользователей к конкурентам. Стейкхолдеры охотнее выделяют дополнительные время и ресурсы на погашение ТД, если убедить их меткими развёрнутыми доводами.

Разработчикам понадобятся:

• Чёткие стандарты кодирования, архитектурные рекомендации.
• Автоматизированные тесты.
• Регулярный аудит и код-ревью. Коллективный обзор выявит больше неполадок и поможет в обмене опытом.
• Рефакторинг.
• Таск-менеджеры (Jira, Trello).

Последние версии инструментов, фреймворков, библиотек.

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

• Обновлять и модернизировать архитектуру. Использовать инкапсуляцию, внедрять модульность и т.д.
• Изучать и применять лучшие практики программирования.
• Рефакторить код. Улучшать его качество, читаемость и эффективность.
• Документировать изменения.
• Тестировать код. Обнаружили баг – написали скрипт, который выявлял бы его. Исправили – запускаем тест и, если проблема не решена, продолжаем над ней работать.
• Проводить аудит и ревью кода.
• Вовремя обновлять инструменты, используемые в разработке продукта.

В плане работы с людьми:

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

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