Как выбраться из технического долга
Многие программисты, особенно неопытные, допускают ошибки или применяют не оптимальные решения. Часто это вынужденная мера – компромисс между качеством и скоростью релиза. Так растёт ком проблем: недоделанные функции, неоптимальные алгоритмы, спорные архитектурные моменты и другие костыли. Это и есть технический долг – все недочёты, которые накопились в коде и ждут своего решения.
Мелкий багаж проблем не критичен, но он может разрастись и выйти из-под контроля. Тут как с кредитом: чем дольше затягивать с возвратом, тем больше придётся отдавать в виде процентов. Ошибки из прошлого обернутся багами в обозримом будущем. Растущие помехи затруднят внедрение новых фич. На решение последующих задач придётся тратить больше времени, чем можно было бы.
На погашение техдолга может уйти много сил, денег и времени. Правильно выстроенные процессы избавят от него с минимальной болью.
Причины возникновения
В большинстве случаев всё из-за недостатка времени. Например, есть некий стартап. Инвесторы вкладывают в него деньги и хотят побыстрее выйти на рынок: обогнать конкурентов, получить прибыль. Оговариваются сроки разработки, и команда стартапа должна справиться до дедлайна. Времени не хватает, приходится «срезать углы»: откладывать какие-то задачи на потом, упрощать тестирование (некоторые места вообще не проверять), составлять только базовую документацию и т.д. Продукт выйдет быстрее, но за счёт ухудшения качества. Если его не наверстать, то груз проблем усложнит разработку.
Есть и другие причины:
- Неправильная архитектура проекта.
- Недостаток опыта и знаний у программистов.
- Отсутствие чётких стандартов разработки. Каждый делает как хочет, и на выходе получаем неоптимальный результат.
- Отсутствие документации. Без регламента программист может неправильно представлять работу системы.
- Недостаточная автоматизация разработки, тестирования, развёртывания. Ручные операции отнимают больше времени и чаще приводят к ошибкам.
- Недостаточное тестирование.
- Откладывание рефакторинга.
- Использование устаревших библиотек, фреймворков.
- Применение инструментов без саппорта. Они часто появляются при разработке аутсорс-проектов. Компания создаёт «внутренние библиотеки», но не сопровождает их официальной поддержкой. Такие продукты — это потенциальные источники ТД.
- Дефицит ресурсов. Не хватает людей, бюджета, инструментов.
- Плохо организованный коллектив. Нет взаимодействия между разными командами, отсутствует менторство.
Выявление технического долга
Технический долг определяют по ряду признаков:
- Архитектура проекта не выдерживает нагрузок или заданных требований.
- Низкая степень модульности компонентов. Большой, неделимый код сложнее понимать и поддерживать.
- Много пометок TODO и FIXME.
- Часто изменяемые участки кода. Скорее всего, они проблемные.
- Низкокачественный код отдельных компонентов.
- Костыли вместо полноценных решений.
- Низкое или нулевое покрытие тестами.
- Невысокая производительность.
- Недостаточная масштабируемость.
- Наличие уязвимостей.
Неполная или отсутствующая документация кода, архитектуры.
Методы погашения
Чем больше «хлама», тем труднее с ним управиться. Мы можем взять это бремя на себя и разобраться с тем, что уже накопилось у вас на проекте. Наша команда проанализирует код: что в нём не так и почему. Мы оценим приоритетность каждой проблемы, составим план работы и уберём до 80% вашего техдолга.
Эту задачу можно выполнить только при комплексном подходе. «Уборка» требует определённых расчётов, действий и работы с людьми.
Главное
Вначале нужно идентифицировать ТД: какие накопились проблемы, почему они возникли (нехватка времени, плохая архитектура, костыли, недостаточное покрытие тестами и т.д.). Для этого нужны код-ревью, аудит системы, общение с разработчиками и пользователями продукта.
Второе – спланировать действия:
- Составить бэклог задач по техническому долгу.
- Рассортировать задачи по приоритетности (степени важности и сложности выполнения). Для этого можно использовать Матрицу Эйзенхауэра, фреймворк RICE. Сначала нужно браться за то, что требует немедленного внимания.
- Рассчитать, хватит ли ресурсов на каждую задачу. Возможно, потребуется больше сотрудников или временное перераспределение тасков.
- Установить сроки выполнения.
- Распределить задания между разработчиками.
Третье – продумать метрики выполнения техдолга. Соответствие кода определённым стандартам, процент покрытия тестами и документацией и т.д. Метрики не должны вызывать несогласие у команды – ей по ним отслеживать прогресс борьбы с ТД.
Четвёртое – выполнять задачи по беклогу. Самый продуктивный метод – закладывать некоторое время от разработки только на технический долг. Можно посвящать 10-30% от очередной итерации или целую итерацию (между проектами), или день в одну-две недели. Крупные компании, которые не справляются с техдолгом, выделяют на него целые группы разработчиков или передают на аутсорс – например, нам.
Работа с людьми
Командные усилия – это единственный выход из технического долга. Нужно объяснять программистам, какие проблемы скопились на проекте, к чему они приведут: ошибкам, нестабильности, замедлению скорости разработки. Следует показывать реальные примеры того, как устранение ТД экономит время, силы и ресурсы. Осведомлённые мотивированные люди справятся лучше тех, кто не заинтересован и не понимает, что происходит.
Другая сторона – это владельцы продукта. «Бизнес» думает категориями рынка, поэтому с ними лучше говорить о финансовых рисках. Растущий техдолг ухудшает качество продукта, тормозит выход новой версии, отталкивает пользователей к конкурентам. Стейкхолдеры охотнее выделяют дополнительные время и ресурсы на погашение ТД, если убедить их меткими развёрнутыми доводами.
Техническая часть
Разработчикам понадобятся:
- Чёткие стандарты кодирования, архитектурные рекомендации.
- Автоматизированные тесты.
- Регулярный аудит и код-ревью. Коллективный обзор выявит больше неполадок и поможет в обмене опытом.
- Рефакторинг.
- Таск-менеджеры (Jira, Trello).
- Последние версии инструментов, фреймворков, библиотек.
Профилактика
Удерживать рост технического долга можно только непрерывной системной работой. Важна отдача от всей команды на каждом этапе разработки.
С самого начала нужно регулярно:
- Обновлять и модернизировать архитектуру. Использовать инкапсуляцию, внедрять модульность и т.д.
- Изучать и применять лучшие практики программирования.
- Рефакторить код. Улучшать его качество, читаемость и эффективность.
- Документировать изменения.
- Тестировать код. Обнаружили баг – написали скрипт, который выявлял бы его. Исправили – запускаем тест и, если проблема не решена, продолжаем над ней работать.
- Проводить аудит и ревью кода.
- Вовремя обновлять инструменты, используемые в разработке продукта.
В плане работы с людьми:
- Вкладываться в обучение команды. Нужны регулярные семинары, презентации, технические митапы и прочие форматы обмена опытом.
- Выстраивать диалог с бизнес-стороной. Коммуникация должна быть прозрачной и деловой. Когда владелец продукта понимает суть техдолга, тогда команде выделяют больше времени на его погашение. В противном случае, будет дисбаланс между качеством и оперативностью релизов.
Полезный совет: если разработчик понимает, что пишет костыль, тогда нужно сразу оставить заметку об этом. Пока воспоминания свежи, информация будет точнее. Так программисты будут сами участвовать в формировании беклога.
Хотите заказать разработку? Заполните форму обратной связи и мы с Вами свяжемся!