Привет, Хаброжители! Сегодня мы хотим рассказать вам побольше о новом предзаказе: «Метрики программной архитектуры. Кейсы, повышающие качество ПО».

Это не монография, а сборник из десяти самостоятельных глав от десяти архитекторов (Форд, Фарли, Лилиенталь, Вудс, Роза и другие), объединённых темой измерения качества архитектуры. Единой теории в книге нет, но есть рабочий код, формулы и параметры оценки, которые можно перенести в проект сразу — от DORA-метрик и фитнес-функций до GQM-подхода.

Десять авторов писали свои главы независимо, и это заметно, какая-то глава может оказаться полезнее других в зависимости от вашего проекта, и книгой «можно пользоваться как регулярно, так и эпизодически». Не стоит ждать сквозного нарратива, единого словаря терминов и общей методологии оценки архитектуры. Вместо этого — десять точек зрения на одну и ту же проблему: как объективно понять, ухудшается архитектура или улучшается, и когда стоит вмешаться.

Первую главу написал Эндрю Хармел-Лоу, он разбирает четыре ключевые метрики DORA - частоту развёртываний, время выполнения доставки, долю неуспешных изменений и время восстановления сервиса — но не как определения из учебника, а как практическую задачу «рефакторинга схемы» пайплайна. Автор последовательно проводит читателя через четыре топологии CI/CD: единый сквозной пайплайн, набор независимых пайплайнов на микросервис, пайплайн из суб-пайплайнов и, наконец, многоступенчатый пайплайн слияния (fan-in), для которого труднее всего сопоставить метку времени коммита с конкретным развёртыванием. Там же разобран неочевидный практический вопрос: «А что делать, если продакшен-среды у команды ещё нет?». Автор предлагает использовать «наивысший доступный уровень среды» как временный эквивалент продакшена, а тестировщиков считать эквивалентом пользователей.

Главы 2 и 8 связаны темой фитнес-функций. Это понятие ввели Форд, Парсонс и Куа в книге «Эволюционная архитектура» (Building Evolutionary Architectures). Рене Вайсс в главе 2 выстраивает «пирамиду фитнес-функций» по аналогии с пирамидой тестирования, различая атомарные и комплексные проверки, а Нил Форд в главе 8 доводит идею до кода: пример с ArchUnit и методом beFreeOfCycles() показывает, как в несколько строк встроить в сборку проверку на циклические зависимости между пакетами. Там же один из самых интересных кейсов книги: история GitHub, где команда заменяла код слияния файлов через инструмент Scientist, параллельно выполняя старую и новую реализации и сопоставляя результаты. Эксперимент запускался более десяти миллионов раз за четыре дня, прежде чем старый код был удалён. Это тот случай, когда «фитнес-функция» перестаёт быть абстракцией и превращается в конкретный инженерный приём с риском, который можно измерить.

Главы от Карола Лилиенталя и Александра фон Цитцевица самые «метрические»: обе предлагают «формулы». Лилиенталь вводит индекс зрелости модульности (MMI) и связывает три когнитивных механизма (группирование, построение иерархий и создание схем) с архитектурными принципами модульности, иерархичности и соответствию паттернам. В книге дана полная таблица весовых коэффициентов и десятибалльная шкала перевода сырых метрик в итоговую оценку. Фон Цитцевиц идёт дальше и вводит собственные метрики Maintainability Level и Structural Debt Index, иллюстрируя их на примере Apache Cassandra. Формулы даны полностью, а примеры расчёта на маленьких графах позволяют проверить их вручную без авторского Sonargraph.

Жоао Роза в шестой главе описывает кейс архитектора Анны, которая проходит путь от рядового разработчика до архитектора решений в финтех-компании, разбирая переход от монолита к «большому распределённому кому грязи» и обратно — через воркшопы EventStorming и построение «дерева KPI», связывающего бизнес-метрики компании (EBITDA, CLV, MAU) с метриками конкретных доменов и, наконец, с техническими показателями вроде частоты развёртываний. Глава прямо ссылается на закон Конвея и на закон Гудхарта (когда мера становится целью, она перестаёт быть хорошей мерой), и буквально на пальцах помогает понять зачем нужны архитектурные метрики. А глава Эойна Вудса логически её продолжает, рассказывая про внешние и внутренние метрики, метрики артефактов и операционные метрики, способы их получения (логи, трассировки, данные измерений, статический анализ, оценки и модели, фитнес-функции).

Десятая глава, написанная Майклом Килингом, стоит немного особняком — это единственная глава, которая опирается на академический подход GQM (goal-question-metric), предложенный Виктором Базили и Дэвидом Вайссом ещё в 1984 году. Килинг подробно разбирает построение GQM-дерева от цели через вопросы к метрикам и данным, приводит практический кейс с сервисом, ограничивающим частоту запросов к API, и описывает формат группового воркшопа для командной выработки метрик — с ролями, материалами и типичными ошибками фасилитации.

В пятой главе (Чичери) описывается не идеальный, а реальный DevOps, где автоматизация оторвана от разработчиков, а команда девопсеров превращается в отдельное подразделение со своими тикетами и сроками. Автор вводит понятие «сдвига ответственности» и разбирает два кейса: нестабильную основную ветку внутри одной компании и замкнутый круг взаимодействия консалтинговой команды с внутренним DevOps клиента. Практическая ценность этой главы высока потому, что автор не делает вид, будто у всех читателей идеальная инфраструктура.

Третья глава Дэйва Фарли — самая короткая и самая абстрактная. Пять атрибутов проектирования (модульность, связность, разделение ответственности, абстракция, связанность) перечислены практически без примеров кода, скорее как манифест, чем как методика.

Разные главы оценивают и измеряют похожие вещи по-разному, используют разные инструменты в качестве референсных и не пытаются свести все в единую систему.

«Главная мысль книги в том, что измерения не являются самоцелью. Метрики нужны, чтобы перейти от наблюдения к развитию и улучшению инженерных практик. Книга будет полезна всем, кто интересуется инженерной аналитикой и анализом эффективности, производительности и качества. При подготовке русского издания мы вместе с издательством уделили значительное время адаптации терминологии к процессам и практикам российских компаний. Надеюсь, что эта работа поможет читателям и повлияет на профессиональную дискуссию об инженерной аналитике и метриках».
- Игорь Курочкин, научный редактор книги, эксперт в Enabling.team.

Оформить предзаказ на книгу: «Метрики программной архитектуры. Кейсы, повышающие качество ПО» можно на нашем сайте.

Для Хаброжителей скидка 35% по промокоду - Предзаказ