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

Технический долг

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

Как может возникать технический долг? Я выделяю основные источники:

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

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

• Изменение требований к сервису, приводящих к формированию технического долга. Все, что не эволюционирует, со временем умирает. Это касается и информационных систем. Появляются новые, более удобные версии библиотек, фреймворков, новые системы сбора метрик и т.д. Архитекторы и техлиды проводят исследования и предлагают новые решения, улучшающие процесс разработки. Требования к внедрению новых решений и приводит к появлению технического долга.

• Работа статик-анализаторов кода (IDE, CI/CD), линтеров (CI/CD). Они формируют набор замечаний по безопасности, эффективности, стилю и т.п.

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

Управление техническим долгом

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

Как избегать появления технического долга? Чтобы предотвращать разрастание хаоса, лучше иметь регламент и следовать ему. Я приведу несколько рекомендаций по управлению техническим долгом, которым следую сам:

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

• Возьмите за правило проводить обязательный ревью кода несколькими коллегами перед принятием мердж реквеста.

• Регулярно проводите ревью архитектуры проектов силами архитектора или техлида.

• Планируйте обновление зависимостей в коде: более свежие библиотеки и т.д. Создавайте задачи и оценивайте сроки. Ведите эту работу системно.

• Поддерживайте актуальной документацию. Для этого одновременно с задачей на разработку создавайте задачу на актуализацию документации. Дополнительно, регулярно проводите ревью актуальности документации (например, раз в квартал).

Continuous Inspection

Отдельно стоит упомянуть о довольно распространенной концепции Непрерывной инспекции кода (Continuous Inspection). Она представляет из себя перечень постулатов, помогающих управлять техническим долгом. Перечислим их:

• Качество кода - общая задача. Вся команда разработки ответственна за поддержание кодовой базы в хорошем состоянии.

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

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

• Проверка качества должна быть автоматизированной. Чем больше автоматизации - тем лучше. Тем самым снижается человеческий фактор упущений при ревью кода.

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

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

Заключение

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

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