Управление техническим долгом
Довольно часто сталкиваюсь с ситуацией разного представления о техническом долге в разработке. Для бизнеса технический долг кажется непрозрачным расходом ресурсов, обосновать необходимость которого для разработки является головной болью. Но тем не менее, управлять техническим долгом нужно, иначе он поглотит вашу компанию и приведет ее к краху.
Технический долг
Что есть технический долг? Более официальную версию вы можете прочесть в Википедии. Я же опишу свое представление. Технический долг (technical debt, tech debt) - это часть невыполненной работы по проекту, не влияющей на текущие функциональные возможности, но необходимой для долгосрочной стабильности системы и простоты добавления новой функциональности в будущем.
Как может возникать технический долг? Я выделяю основные источники:
- Умышленное упрощение разрабатываемого сервиса, приводящее к расхождению с запланированной архитектурой. Такое упрощение может быть вызвано сжатыми сроками, некомпетентностью разработчиков и внешними ограничениями.
- Ошибки в проектировании. Архитектура не отражает требуемые бизнес-процессы в нужной мере, или не учтены иные требования: нагрузка, отказоустойчивость и т.д.
- Изменение требований к сервису, приводящих к формированию технического долга. Все, что не эволюционирует, со временем умирает. Это касается и информационных систем. Появляются новые, более удобные версии библиотек, фреймворков, новые системы сбора метрик и т.д. Архитекторы и техлиды проводят исследования и предлагают новые решения, улучшающие процесс разработки. Требования к внедрению новых решений и приводит к появлению технического долга.
- Работа статик-анализаторов кода (IDE, CI/CD), линтеров (CI/CD). Они формируют набор замечаний по безопасности, эффективности, стилю и т.п.
- Обнаруженные недочеты в ходе ревью кода. Например, архитектор или техлид анализируют существующие проекты и вносят предложения по улучшению архитектуры. Сформированные замечания/рекомендации формируют технический долг.
Управление техническим долгом
Мы обсудили, что такое технический долг и как он возникает. Но как управлять техническим долгом? Основное правило здесь - старайтесь всеми силами избегать его появления. Если же это неизбежно, обязательно имейте отдельную пользовательскую историю для технического долга проекта, и сразу же в момент принятия решения или реализации, влекущее за собой появление технического долга, оформляйте это в виде задач внутри истории. Обязательно оценивайте сроки завершения и требуемое время на решение. В дальнейшем, вам будет легче вести диалог относительно приоритизации и выделения ресурсов на закрытие технического долга.
Как избегать появления технического долга? Чтобы предотвращать разрастание хаоса, лучше иметь регламент и следовать ему. Я приведу несколько рекомендаций по управлению техническим долгом, которым следую сам:
- Используйте доступные вам системы статического анализа кода, линтеры и прочие механизмы автоматической проверки. Это предотвратит ухудшение состояния кодовой базы со временем.
- Возьмите за правило проводить обязательный ревью кода несколькими коллегами перед принятием мердж реквеста.
- Регулярно проводите ревью архитектуры проектов силами архитектора или техлида.
- Планируйте обновление зависимостей в коде: более свежие библиотеки и т.д. Создавайте задачи и оценивайте сроки. Ведите эту работу системно.
- Поддерживайте актуальной документацию. Для этого одновременно с задачей на разработку создавайте задачу на актуализацию документации. Дополнительно, регулярно проводите ревью актуальности документации (например, раз в квартал).
Continuous Inspection
Отдельно стоит упомянуть о довольно распространенной концепции Непрерывной инспекции кода (Continuous Inspection). Она представляет из себя перечень постулатов, помогающих управлять техническим долгом. Перечислим их:
- Качество кода - общая задача. Вся команда разработки ответственна за поддержание кодовой базы в хорошем состоянии.
- Актуальность информации. Информация о состоянии кодовой базы должна обновляться планово для качественной оценки.
- Данные о качестве должны быть как в абсолютных, так и в разностных значениях. То есть, мы должны иметь возможность оценить изменение от версии к версии, от недели к неделе и т.д.
- Проверка качества должна быть автоматизированной. Чем больше автоматизации - тем лучше. Тем самым снижается человеческий фактор упущений при ревью кода.
- Стандарты качества должны быть едины для всех проектов. Стандарты могут быть очень разными, отличаться как от компании к компании, так и от команды к команде. Но они должны существовать, быть регламентированы и доведены до всех вовлеченных. Вы можете их актуализировать с учетом пожеланий всех членов команды, но решения об изменении лучше принимать коллегиально. Как говорится, одна голова хорошо, а две (и более) - лучше.
- Все новые замечания должны иметь ответственного. Каждое выявленное замечание должно быть закреплено за конкретным разработчиком. Без ответственного не ожидайте результата.
Заключение
Работа с техническим долгом - системная игра в долгую. Она призвана предотвращать снижение продуктивности команд разработки со временем. Для бизнеса здесь важно понимать, что стоимость поддержки при развитии системы с течением времени будет увеличиваться. И чем больше будет размер технического долга, тем сложнее и дороже будет разрабатывать новую функциональность и исправлять ошибки в текущей. Работать с техническим долгом необходимо планово, иметь регламенты и общее понимание всех вовлеченных участников.
При подготовке данной публикации много полезных мыслей было представлено Александром Ярухиным, экспертом по карьерному росту в ИТ.
О том, как проектировать и создавать системы, стоимость сопровождения и развития которых не растет со временем, я рассказываю в своем телеграм-канале solonkov.team. Там же вы сможете найти аудио-версии статей, задать интересующие вас вопросы и обратиться за консультацией.