Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study (ICSE’25) (Рубрика #Architecture) Наконец-то у меня дошли руки написать про этот интересный whitepaper про связь качества архитектуры с нагрузкой на поддержку решения и восприятия инженерами самого проекта. Лид автором этой статьи была Yuanfang Cai, профессор в Drexel University и автор метрик применяемых метрик, а также команда Google Developer Infrastructure / Engineering Productivity Research (Ciera Jaspan и др.) Авторы взяли данные - 1200+ проектов внутри Google (C++/Java). - Логи разработки: commits, LOC (lines of code) и Active Coding Time; отдельно мерили их в разрезе "фичи" vs "багфиксы" - 7200 ответов инженеров из регулярного опроса: насколько техдолг/избыточная сложность мешали работе (подробнее про этот опрос было в статье ребят из Google "Measuring Developer Experience With a Longitudinal Survey", что я уже разбирал) Цель всего приседания была в том, чтобы заменить "ощущения техдолга" на измеримые связи: архитектура → бремя сопровождения → настроение разработчиков. Кстати, про техдолг ребята из Google уже публиковали крутую статью "Defining, measuring and managing technical debt", которую я уже разбирал Измеряли они следующие три категории 1️⃣ Архитектурная сложность - Propagation Cost (PC): насколько широко расползаются изменения по зависимостям - Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули - Архитектурные запахи: циклические зависимости, co-change без явных зависимостей, нестабильные интерфейсы, проблемы наследования и т.п. 2️⃣ Maintenance burden - Доля усилий на багфиксы: по commits, LOC (lines of code), ACT (active coding time) 3️⃣ Developer sentiment - Ответы на вопросы из опросы вида "тормозит ли меня техдолг" Методология выглядела так - Для каждого проекта считают PC/DL/запахи по dependency graph + считают "bugfix ratio" по истории изменений - Дальше делают статистический анализ (корреляции/значимость) между тремя слоями В итоге у них на выходе получились результаты, что - Более сложная архитектура (PC↑, smells↑) связана с тем, что команда тратит больше доли усилий на багфиксы и меньше - на развитие - Чем больше "feature work" у команды, тем реже инженеры говорят, что техдолг их тормозит - "Архитектура <-> недовольство" во многом проявляется через рост багфиксов: когда вы живёте в поддержке, техдолг становится осязаемым Отдельно стоит отметить, что исследование нашло корелляцию, но это не причинно-следственная связь. Но это частая картина для сложных методологий исследований, что через a/b тест не катанешь. В следующем посте я расскажу свои мысли, а что можно из этого забрать себе, чтобы контролировать качество архитектуры и не стать техническим банкротом. P.S. Я рассказывал про многие статьи ребят из Google, у них отлично выстроена методология и есть очень интересные результаты - подробнее можно посмотреть в подборке из двух постов: 1 и 2 #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes