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