Когда использовать
Когда есть архитектура (существующая или проектируемая) и нужен взгляд «сверху»: правильно ли разбито на компоненты, где она сломается под нагрузкой, какие риски и техдолг, что упрощать. В отличие от код-ревью — смотрим решение, а не строки. Роль — software architect на ревью. Результат: оценка по аспектам, узкие места, риски с severity и приоритизированные рекомендации.
Промт (бери и вставляй)
Ты — software architect на архитектурном ревью. Оцени РЕШЕНИЕ (компоненты и связи), а не отдельные строки кода. Будь конкретным и честным.
ЧТО РЕВЬЮ: «<ВСТАВЬ: описание архитектуры / схема компонентов / список сервисов и как связаны / ключевые куски кода>».
СТЕК: <языки/фреймворки/БД/инфра>. МАСШТАБ И ТРЕБОВАНИЯ: <нагрузка, SLA, команда, что критично — скорость/надёжность/стоимость>. СТАДИЯ: <проект / MVP / растём / легаси>.
ЧТО БЕСПОКОИТ: «<если есть конкретные сомнения>».
Разбери по аспектам, для каждой находки — severity (критично / важно / на будущее) и обоснование:
1. Разбиение и связность: правильные ли границы компонентов, нет ли лишней связанности (tight coupling), нарушений ответственности, циклов зависимостей.
2. Данные: модель и хранение, консистентность, узкие места по чтению/записи, миграции.
3. Масштабируемость и производительность: где сломается при росте ×10/×100, что станет бутылочным горлышком, состояние/кэш/очереди.
4. Надёжность и отказоустойчивость: единые точки отказа, что при падении части системы, ретраи/идемпотентность, согласованность.
5. Безопасность (на уровне архитектуры): границы доверия, аутентификация/авторизация между компонентами, хранение секретов/ПД.
6. Эксплуатируемость: наблюдаемость (логи/метрики/трейсинг), деплой, откат, сложность поддержки.
7. Технический долг и оверинжиниринг: где переусложнено для текущей стадии, а где, наоборот, заложена мина.
В конце: 3–5 приоритетных рекомендаций (что чинить первым и почему), 1–2 альтернативных подхода с trade-offs, и что НЕ трогать (работает — не ломай). Если данных для вывода мало — скажи, чего не хватает, не фантазируй про незнакомые части.
Пример заполнения
Что ревью: «монолит на Node + PostgreSQL, всё синхронно; добавили отправку email и генерацию PDF прямо в HTTP-запросе; один инстанс». Масштаб: растём, 50 rps, начались таймауты. Стадия: MVP перерастает в продукт.
Ожидаемый ответ ИИ: [критично] тяжёлые задачи (email, PDF) в синхронном запросе → таймауты и блокировка воркеров → вынести в очередь (BullMQ/Redis) с воркерами; [критично] один инстанс = единая точка отказа, нет горизонтального масштабирования; [важно] нет идемпотентности — ретраи задвоят письма; [важно] наблюдаемость: не видно, где время уходит, добавить метрики/трейсинг; [на будущее] монолит ок для стадии, не дробить на микросервисы преждевременно (оверинжиниринг); приоритеты — очередь → стейтлес-инстансы за балансером → идемпотентность; альтернативы с trade-offs; «не трогать» — саму БД-модель, она адекватна. Где про незнакомый модуль мало данных — просит детали.
Вариации
- Один аспект вглубь. «Сфокусируйся только на масштабируемости» или «только на отказоустойчивости» — детальный разбор по оси.
- ADR. «Оформи рекомендации как Architecture Decision Records: контекст → решение → последствия».
- Два дизайна. «Сравни текущую архитектуру с предлагаемой альтернативой — таблица плюсов/минусов и когда какая лучше».
Про-советы
- Контекст стадии и требований решает: для MVP «достаточно хорошо» и для нагруженного продукта — разные ответы. Без масштаба, SLA и размера команды ИИ либо переусложнит, либо упустит риск. Всегда давайте требования и стадию.
- Самое ценное — приоритеты и «что НЕ трогать»: ИИ любит предложить «перепишите на микросервисы» там, где это оверинжиниринг. Требуйте severity и защиту от преждевременного усложнения.
- Это глубокое архитектурное суждение — берите сильнейшую модель (Opus/GPT-4-класс) с большим контекстом; для высоких ставок прогоните ДВА независимых ревью и сравните. ИИ-ревью дополняет, но не заменяет живого архитектора и нагрузочное тестирование.