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