Книжный куб

Как взять идеи 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