Издательский дом «Питер» открыл предзаказ на книгу «Метрики программной архитектуры. Кейсы, повышающие качество ПО», где собраны 10 самостоятельных глав от 10 архитекторов. Для российской IT-аудитории это редкий случай, когда метрики архитектуры обсуждаются не на уровне лозунгов про «качество», а через код, формулы, пайплайны и конкретные способы проверить, улучшается система или медленно едет в сторону дорогого ремонта.
О книге сообщает Habr / Карьера. По описанию издателя, это не единый учебник с общей теорией, а набор независимых текстов от практиков вроде Нила Форда, Дэйва Фарли, Карола Лилиенталя, Эойна Вудса и Жоао Розы. Общий вопрос у них один: как перестать спорить о качестве архитектуры на уровне вкусов и начать измерять его так, чтобы результаты можно было применить в проекте, а не положить в презентацию для квартального созвона.
В этом и есть главный нерв книги. Архитектура в большинстве команд по-прежнему живет между двумя неудобными крайностями. С одной стороны, есть инженерная интуиция: «монолит уже трещит», «микросервисы расползаются», «связность растет, а скорость падает». С другой — KPI, которые часто фиксируют уже последствия, а не причины. Сборник пытается занять промежуточную позицию: дать набор наблюдаемых сигналов, по которым можно понять, когда архитектура помогает продукту, а когда начинает тормозить разработку, эксплуатацию и изменения.
От DORA до fitness functions
Одна из самых прикладных частей книги — первая глава Эндрю Хармел-Лоу про четыре DORA-метрики: частоту развёртываний, lead time изменений, долю неуспешных изменений и время восстановления сервиса. В описании особенно интересно не перечисление самих метрик — их рынок уже выучил, — а попытка приземлить их на реальную топологию CI/CD. Автор разбирает четыре варианта: сквозной единый пайплайн, независимые пайплайны для микросервисов, пайплайн из субпайплайнов и многоступенчатую схему fan-in, где уже не так просто понять, какой коммит привел к какому деплою. Для команд, у которых delivery-процесс выглядит не как в брошюре про platform engineering, а как набор исторически сложившихся компромиссов, это полезнее очередного списка «правильных» определений.
Там же поднимается вопрос, который обычно выпадает из красивых методик: что считать продакшеном, если продакшена как такового у команды еще нет. Предлагаемый ответ прагматичный: использовать самый высокий доступный уровень среды как временный эквивалент production, а тестировщиков рассматривать как замену пользователям. Это не академическая чистота, но для команд ранней стадии, внутренних платформ или проектов с тяжелым контуром согласований такой подход понятен: лучше получить приблизимую метрику, чем ждать идеальных условий и не измерять ничего.
Две другие заметные главы связаны с fitness functions — концепцией, которую Нил Форд, Ребекка Парсонс и Патрик Куа популяризировали в «Эволюционной архитектуре». Рене Вайсс описывает «пирамиду fitness functions» по аналогии с тестовой пирамидой, разделяя атомарные и комплексные проверки. А Форд показывает более приземленный вариант: как встроить архитектурную проверку прямо в сборку. Пример с ArchUnit и методом beFreeOfCycles() выглядит почти нарочито простым, но именно в этом ценность: архитектурное требование перестает быть устной договоренностью и становится исполняемым правилом. Самый сильный кейс здесь — история GitHub, где замена механизма слияния файлов проверялась через Scientist: старая и новая реализации выполнялись параллельно, а результаты сравнивались. Эксперимент прогнали больше 10 миллионов раз за четыре дня, прежде чем удалить старый код. Для разработчиков это, пожалуй, самый внятный ответ на вопрос, зачем вообще нужны метрики архитектуры: чтобы инженерный риск можно было считать, а не описывать прилагательными.
Когда формулы полезны, а когда опасны
Самые «математические» главы в сборнике — у Карола Лилиенталя и Александра фон Цитцевица. Лилиенталь вводит индекс зрелости модульности, MMI, и связывает его с когнитивными механизмами, через которые люди вообще понимают сложные системы: группирование, иерархии и схемы. В книге, по описанию издателя, есть таблицы весов и шкала перевода сырых показателей в итоговую оценку. Фон Цитцевиц идет дальше и предлагает собственные метрики Maintainability Level и Structural Debt Index, показывая расчеты на примере Apache Cassandra. Важный плюс в том, что формулы и примеры разбора на маленьких графах позволяют хотя бы вручную проверить логику, а не принимать инструмент на веру только потому, что у него убедительный дашборд.
Но книга, судя по пересказу, ценна не только там, где дает новые индексы. Жоао Роза в шестой главе раскладывает более знакомый для бизнеса и продуктовых команд сценарий: путь от монолита к большому распределенному комку грязи и попытку вернуться к управляемой структуре. В центре кейса — архитектор Анна из финтех-компании, EventStorming и дерево KPI, которое связывает EBITDA, CLV и MAU с доменными и техническими показателями вроде частоты развёртываний. Такой переход от бизнес-метрики к техническому сигналу обычно и ломается в реальных компаниях: либо связь остается декларативной, либо каждая функция начинает оптимизировать свой участок без общего контекста. Здесь важна не сама формулировка дерева KPI, а напоминание о двух старых, но живых законах — Конвея и Гудхарта. Первый говорит, что архитектура повторяет структуру коммуникаций в компании. Второй — что метрика, превращенная в цель, быстро перестает быть нормальной метрикой. Для IT-директоров и продактов это, возможно, самая полезная часть всей истории: проблема не в том, что инженеры мало считают, а в том, что бизнес часто требует считать не то.
Глава Эойна Вудса логично продолжает эту линию, разделяя внешние и внутренние метрики, метрики артефактов и операционные метрики, а также способы их получения: логи, трассировки, измерения, статический анализ, экспертные оценки, модели и те же fitness functions. А Майкл Килинг в десятой главе возвращает разговор к более академическому каркасу GQM — goal-question-metric, который Виктор Базили и Дэвид Вайсс предложили еще в 1984 году. Это, пожалуй, самая полезная оптика для зрелых команд: сначала формулировать цель, потом вопрос, и только потом выбирать показатель. Иначе рынок снова скатывается в любимую игру «соберем побольше цифр, а смысл придумаем потом».
Есть и еще одна деталь, из-за которой книга может попасть не только в стопку «почитать архитектору». В пятой главе Чичери разбирается не образцовый DevOps, а вполне земной: автоматизация отделена от разработки, девопс-команда живет как отдельное подразделение, а взаимодействие строится через тикеты и сроки. Автор говорит о «сдвиге ответственности» и рассматривает два кейса — нестабильную основную ветку внутри компании и замкнутый круг общения между консалтингом и внутренним DevOps клиента. Для российских команд это узнаваемый ландшафт. Рынок много лет продавал DevOps как новую культуру, но в реальности он нередко превращался в новый забор между функциями. Если книга честно работает с такой реальностью, а не только с идеальной картинкой из конференционных докладов, это уже аргумент в ее пользу.
Отдельно издатель подчеркивает, что при подготовке русского издания терминологию адаптировали под процессы и практики российских компаний. Научный редактор книги Игорь Курочкин из Enabling.team в цитате для анонса формулирует главную идею без лишней романтики: измерения не самоцель, а способ перейти от наблюдения к улучшению инженерных практик. На фоне моды на универсальные scorecard-подходы мысль трезвая. Вопрос теперь в другом: сможет ли рынок использовать метрики архитектуры как инструмент проектных решений, а не как еще один слой отчетности, который красиво выглядит в BI, но почти не влияет на то, как команды строят и меняют системы.