Технический долг и способы им управлять

Что такое технический долг

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

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

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

Согласно исследованию Stripe и The Harris Poll, технический долг может обходиться бизнесу в 85 млрд долларов ежегодно. Разработчики компаний потенциально могут тратить на поддержку «грязной» кодовой базы — отладку, модификацию, поиск ошибок — по 17,3 часа каждую неделю. Это явление оттягивает силы команды на сражение с багами, недоработками — мусором в коде программного обеспечения.

Когда рефакторинг необходим бизнесу

Рефакторинг – оптимизация программной архитектуры. Процедура не меняет функции приложения – модифицируется только структура кода.
Бизнес нуждается в рефакторинге, когда не получается масштабировать продукт из-за «костылей» и недоработок. При этом количество исправлений на разных платформах может перевалить за сотни, тогда команда перестанет справляться с объемом работ. Как следствие, скорость доставки изменений критически снизится:

• Сроки релиза продолжат срываться, а time-to-market и финансовые потери вырастут, поскольку цикл выпуска продукта затянется.
• Конкурентоспособность бизнеса упадет из-за медленного по сравнению с конкурентами обновления функционала. 

Стоит ли сокращать технический долг и проводить рефакторинг прямо сейчас — зависит от бизнес-цели продукта. 

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

“Если не стыдно за первую версию — вы вышли на рынок слишком поздно”

На начальном этапе развития проекта техдолг допустим в таких случаях: 

• не мешает запуску;
• это осознанное, временное решение IT-команды и руководства.

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

«Укрощение» технического долга команды

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

Оценка техдолга

Система контроля версий под рукой у каждого программиста. С помощью такого типа программ получится узнать состояние проекта.

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

Проверьте, сколько раз IT-специалисты просматривают или корректируют тот или иной файл. Если многократно, плюс он разместился на 2000+ строках, – по видимым параметрам его сложнее поддерживать, чем файл на 50 строках. 

Программы статической диагностики сложности проекта непрерывно отслеживают слабые места. Обнаруженные проблемные фрагменты – кандидаты на рефакторинг.

Автоматизация проверки качества

DevOps-инструменты помогают находить подозрительный код.

Статические анализаторы – плагины непрерывного анализа, такие как SonarQube, – интегрируют в CI/CD-пайплайны для автоматического сканирования.

Анализаторы не прорабатывают массивные проблемы, не определяют сложности в стеке или архитектуре, но они полезны:

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

Code review

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

Метод помогает анализировать задачи, практики безопасности, среду CI/CD.

Принципы Code Review: 

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

Привлечение внешнего аудитора

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

Критерии подбора внешнего аудитора: 

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

После перечисленных шагов можно взяться за оптимизацию техдолга. Главное – не превращать ее в единственную задачу команды. 
Если не хватает опытных кадров, расширьте внутренний штат выделенной командой из проверенной аутсорс-компании. Мы в Umbrella IT готовы подключиться на любом этапе, чтобы устранить до 80% технического долга за 1 месяц.