🏗️ Архитектурное ревью в условиях большого проекта

Коллективная разработка программного обеспечения давно стала нормой — над продуктом одновременно работают десятки, а то и сотни инженеров. В таких условиях важно договариваться о технических решениях, чтобы обеспечить согласованность и устойчивость системы. Одной из устоявшихся практик является код-ревью: она почти всегда применяется, как только в проекте появляются первые несколько разработчиков. Архитектурное ревью — менее универсальная практика. Она появляется не сразу, и ее необходимость не всегда очевидна.

Когда проект только начинается и в команде работает до 10–15 инженеров, процессы устроены определенным образом. Основные технические решения формулирует один человек — условный CTO, который хорошо понимает текущие задачи и держит архитектуру в голове. Команда тесно взаимодействует, все в курсе, кто чем занимается, решения принимаются быстро. В этот период основная цель — запустить продукт, создать первую версию, которая приносит хоть какую-то ценность. В таких условиях тщательно выверенные архитектурные решения не всегда оправданы: через полгода многое может измениться, и текущий подход окажется неактуальным.

Ситуация меняется, когда продукт достигает зрелости. Например, в нем работают десятки команд, по 10 человек в каждой. Архитектура становится распределенной, и уже не все участники одинаково хорошо понимают, как устроены соседние компоненты, какие решения были приняты ранее и по каким причинам. Появляется накопленная экспертиза — внутри организации есть специалисты, способные дать качественную обратную связь по архитектурным предложениям. Также накапливаются решения, проверенные на практике именно в этом продукте — их можно и нужно использовать повторно, не изобретая все заново.

Кроме того, на этом этапе, как правило, стабилизируется бизнес-модель. Новые модули и компоненты разрабатываются с расчетом на длительную эксплуатацию: 3–5 лет и более. Они должны быть понятны и поддерживаемы, даже если автор кода покинет компанию или вся команда сменит зону ответственности.

В таких условиях фокус смещается в сторону устойчивых, долгосрочных решений. И архитектурное ревью становится не просто полезной практикой, а необходимым инструментом. Это способ заранее выявить риски, согласовать технические подходы и обеспечить управляемое развитие системы в долгосрочной перспективе.

Цели архитектурного ревью

Архитектурное ревью преследует несколько ключевых целей, которые напрямую влияют на успех проекта.

Во-первых, это предотвращение дорогостоящих ошибок до начала активной разработки. Когда проблемы выявляются на ранних этапах, их исправление требует минимальных ресурсов. Чем дальше мы продвигаемся в реализации, тем выше становится стоимость внесения изменений.

Во-вторых, архитектурное ревью повышает устойчивость решений к изменениям требований. Опытные архитекторы знают, что единственное постоянное в разработке программного обеспечения — это изменения. Требования будут меняться, бизнес-модели будут эволюционировать, и хорошая архитектура должна быть достаточно гибкой, чтобы адаптироваться без полного переписывания системы.

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

Как проходит архитектурное ревью

Архитектурное ревью обычно проводится в случае существенных изменений, например:

1. при разработке нового компонента или сервиса;
2. при внесении существенных изменений в существующую систему;
3. при изменении взаимодействия между доменами или командами;
4. при использовании новых технологий, библиотек или подходов, ранее не применявшихся в продукте.

Его проводит ведущий инженер с глубокой экспертизой в проекте и хорошим пониманием общей технической архитектуры продукта. За время своей практики я провёл десятки таких ревью для различных проектов. Несмотря на различия в предметной области и используемых технологиях, существует набор универсальных вопросов, которые помогают оценить архитектурное решение:

1. Целеполагание — что будет являться результатом изменений.
2. Какие компоненты добавляются или изменяются — что именно появляется в системе и как это влияет на уже существующую архитектуру.
3. Схемы взаимодействия между компонентами — API, протоколы, синхронность, очереди и т. д.
4. Выбор технологий — языки, фреймворки, базы данных, внешние сервисы.
5. Работа с данными — структура, объёмы, схемы хранения, выбор БД.
6. Миграция системы — как будет происходить переход от текущего состояния к новому.
7. Нагрузка — какая ожидается интенсивность использования и как система будет с ней справляться.
8. Отказоустойчивость — что происходит, если отдельные компоненты выходят из строя. Останавливается ли вся система или лишь её часть? (Обычно цель — частичная деградация, а не полный отказ.)
9. И другие аспекты, зависящие от контекста: безопасность, соответствие стандартам, мониторинг, DevOps-аспекты и т. д.

Отвечая на эти вопросы, ревьюер старается подвергнуть решение критическому анализу, выявить возможные слабые стороны и найти пути для улучшения предложенного решения. Примеры типовых вопросов, которые задаёт себе ревьюер, могут выглядеть следующим образом:

1. Можно ли использовать уже существующие компоненты?В больших организациях часто уже есть библиотеки и сервисы, решающие типовые задачи. Переизобретение — это лишние затраты времени и ресурсов.
2. Насколько архитектура масштабируема и устойчива к изменениям?Система должна работать не только сегодня, но и в будущем, когда увеличится нагрузка или изменятся требования.
3. Сможем ли мы поддерживать это решение через год?Архитектурные решения должны быть понятны не только авторам, но и другим разработчикам. Сложные и “хрупкие” подходы часто плохо переносят смену команды или персонала.

Принцип минимизации энтропии

В физике энтропия — это мера беспорядка в системе. В разработке программного обеспечения энтропия проявляется как технологический разнобой, несогласованность решений и отсутствие единых стандартов. И чем больше проект, тем активнее растет энтропия, если ее не контролировать.

Большое количество разнородных инструментов создает множество проблем: сложности с поддержкой, трудности при онбординге новых разработчиков, разрозненная экспертиза и, как следствие, замедление разработки.

Унификация технологического стека — один из способов борьбы с энтропией. Меньше фреймворков означает более глубокую экспертизу в каждом из них. Меньше языков программирования — больше разработчиков, способных поддерживать любую часть системы. Меньше систем мониторинга — более целостный взгляд на работу приложения.

Архитектурное ревью играет ключевую роль в сохранении этой целостности. Например, при рассмотрении нового решения важно оценить, соответствует ли оно существующим практикам в области API-дизайна или следует ли принципам event-driven архитектуры, принятым в организации.

Соответствие технологической стратегии

Любая крупная организация имеет технологическую стратегию — набор принципов и направлений, которые определяют развитие технической инфраструктуры. Архитектурное ревью выступает как фильтр, который сверяет каждое новое решение с этими стратегическими целями.

Рассмотрим пример: если организация приняла Domain Driven Design (DDD) как основополагающий принцип разработки, то каждое архитектурное решение должно отражать этот подход. Границы доменов должны быть четко определены, агрегаты и сущности должны соответствовать бизнес-концепциям, а взаимодействие между доменами должно происходить через четко определенные контракты.

Соответствие технологической стратегии — это не догма, а руководство. Иногда вполне обоснованно отклониться от принятых практик, если этого требуют особенности задачи. Но такие отклонения должны быть осознанными и хорошо аргументированными.

Работа с метриками

Современная разработка немыслима без метрик. На архитектурном ревью важно обсудить не только то, как система будет работать, но и как мы будем знать, что она работает правильно.

Здесь рассматриваются как технические, так и продуктовые метрики. К техническим относятся такие показатели, как время отклика, пропускная способность, использование ресурсов (CPU, память, диск). Продуктовые метрики — это более высокоуровневые показатели, отражающие характеристики самого продукта. Они сильно зависят от контекста конкретного продукта. В качестве примеров можно привести:

1. среднюю скорость релиза новой версии данных (например, для навигационного сервиса),
2. долю автоматических ответов чат-бота,
3. успешность выполнения бизнес-операций,
4. удовлетворенность пользователей.

Отслеживание продуктовых метрик особенно важно, поскольку именно они находятся ближе всего к целевой функции разрабатываемого ПО. Нередко бывает, что технические метрики в пределах нормы, тогда как продуктовые показатели снижаются. Это может указывать на скрытые проблемы в отдельных компонентах, которые по каким-то причинам не отражаются на технических метриках. Кроме того, причина может находиться на более высоком уровне, например в организации процессов или в неожиданном поведении пользователей, которое не фиксируется на техническом уровне, но напрямую влияет на восприятие продукта конечным пользователем. Подобные ситуации требуют особого внимания и дополнительного анализа при эксплуатации системы.

Архитектурное ревью — это не только обсуждение того, как система будет спроектирована, но и как она будет эксплуатироваться. Хорошо спроектированная система предусматривает механизмы наблюдаемости, которые позволяют оперативно выявлять и устранять проблемы.