Как взять идеи Google и построить себе похожий контроль качества архитектуры (Рубрика #Architecture)

В прошлом посте мы разбирали whitepaper от ребят из Google "Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study". А сейчас я хотел бы поговорить про практические шаги, что можно сделать у себя в компании, если вы не Google, но тоже хотите контролировать качество архитектуры и размер техдолга.

1️⃣ Сформулируйте "maintenance burden" так, чтобы его можно было считать
Самый практичный вариант - доля багфиксов vs фич за период:
- % задач типа Bug в трекере
- % PR/коммитов, привязанных к Bug
- % LOC (или хотя бы файлов), изменённых ради Bug

2️⃣ Соберите минимум данных (обычно уже есть)
- Git/PR-логи: кто/когда/что менял (changed files, размер).
- Issue tracker (Jira и т.п.): тип задачи (bug/feature), компонент/сервис, команда.
- Dependency graph: зависимости между пакетами/модулями/сервисами (из build graph, import graph, API calls).
- Active coding time по задачам или DAT (Diff Authoring TIme), которым так хвалилась запрещенная в России Meta и про который я уже рассказывал
- Если нет Active Coding Time, то начните с прокси: lead time PR, время ревью, размер batch’ей (а потом все-таки соберите ACT)

3️⃣ Архитектурные метрики: начните "дёшево", потом усложняйте
Метрики из приведенного выше whitepaper конечно крутые, но сложные. Я говорю про
- Propagation Cost (PC): насколько широко расползаются изменения по зависимостям
- Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули
В академии есть DV8 от авторов оригинального исследования (Yuanfang Cai, Rick Kazman) или условный Sonar в качестве коммерческого инструмента. Но для старта хватит
- Отслеживать циклы на уровне модулей/сервисов (SCC)
- Считать fan-in/fan-out, транзитивный fan-out
- Отслеживать co-change кластеры: файлы часто меняются вместе, хотя "по архитектуре" не должны
По правилу Парето мы так найдем 20% проблем, что приносят 80% боли

4️⃣ Склейте всё в регулярный отчёт (по кварталам/месяцам)
На уровне repo/сервиса/команды:
- Тренд coupling/циклов/co-change
- Тренд bugfix ratio
- Микро-опрос 1 вопрос раз в квартал: "насколько техдолг/сложность мешали вам работать?"
Важно искать не виноватых, а проблему в системе: high coupling + растущий bugfix ratio = кандидат #1 на тех-инвестиции

Если воспользоваться этим алгоритмом, то у вас будет набор карт на руках, с которыми никакой техдолг не страшен
- У вас будут аргументы для рефакторинга в цифрах (и разговор с бизнесом пройдет на понятном им языке)
- У вас будет внятная приоритизация: какие 2–3 hotspot’а чинить в первую очередь
- Вы увидите ранние сигналы деградации: поймаете тренды до того, как команда уйдёт в вечный багфикс
- Вы улучшите DevEx и скорость доставки фич как следствие

Но важно не облажаться и не наступить в анти-паттерны
- Не превращайте метрики в KPI людей/команд - будет гейминг
- Не ставьте одинаковые абсолютные пороги по метрикам - нужны базовые нормы "что ок" для вашего домена;
- Не пытайтесь получить одну метрику техдолга - он многомерен и метрики - это сигнал, а не приговор. Дальше нужны дизайн‑ревью и инженерная оценка найденных проблем

Если бы я делал это в компании, то попробовал бы
- Катануть пилот на 10–20 репозиториях/сервисах
- Собрал бы базовую панель метрик, перечисленных выше
- Подождал сбора результатов, напрмер, квартал
- Дальше сделал бы точечные рефакторинги (благо сейчас рефакторинг становится сильно дешевле, если его делать с помощью AI-инструментов)
- Сравнил бы "до/после" по bugfix ratio и скорости доставки
- Если бы метрики улучшили, то планировал бы дальше раскатку

В общем, с точки зрения алгоритма примерения тут нет никакого rocket science, но дьявол кроется в деталях:)

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes