Рецензирование чужого проекта

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

Провалить эту лабу легко: написать четыре абзаца вежливых общих слов, которые автор прочитает и забудет. Против этого работает одно правило.

Запуск вместо чтения

«Развернул по README — упало на третьем шаге, вот лог» — факт. С ним нельзя не согласиться, его нельзя объяснить разницей во вкусах, он чинится.

«Мне кажется, архитектура странная» — мнение. Автор его проигнорирует, и будет прав: у него есть ADR, а у вас — ощущение.

У двух ролей это заложено в саму работу: Delivery разворачивает чужой проект по README, Quality прогоняет чужие evals. Остальным двум нужно дотянуться до той же измеримости:

Заметьте, что во всех четырёх случаях рецензент что-то запускает. Рецензия, в которой нет ни одного запуска, — это не рецензия, а впечатление.

Что замечанием не является

Три вещи, которые в рецензию писать не надо:

• Стиль кода. Табы, кавычки, длина строки — работа линтера. Если у проекта настроен ruff, вы спорите не с автором, а с его конфигом.
• Сам выбор стека. Взяли Postgres вместо Mongo — это решение, и оно зафиксировано в ADR. Спорить можно с ценой решения («вы написали, что долга нет, но вот он»), а не с самим выбором.
• «Я бы сделал иначе». Без продолжения «потому что вот здесь ломается» это не замечание, а автобиография.

Обратная сторона: если архитектурное решение неочевидное, а ADR на него нет — вот это замечание, и сильное. Необъяснённая граница или неожиданный компонент в схеме — дыра в проекте, а не мелочь оформления.

Порог значимости

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

Договоритесь с собой до начала:

1. Блокирующее — ломает поведение, роняет запуск, открывает дыру в безопасности, делает заявленные цифры невоспроизводимыми. Пишем подробно, с логом и шагами воспроизведения.
2. Существенное — работает, но в архитектуре или спеках есть расхождение, которое аукнется. Пишем коротко, с указанием места.
3. Остальное — списком в конце, без требования исправить.

Пропорция здорового ревью: два-три пункта первого и второго типа, а не двадцать пунктов третьего.

Формат

Рецензия — такой же артефакт, как всё остальное: review-<команда>.md в вашем репозитории, as-code.

# Рецензия на проект «Тренажёр к экзамену», команда 04

## Что запускал
- Развернул по README на чистой Ubuntu 24.04: `docker compose up` — упал
  на миграциях, лог ниже. Заработало после ручного `alembic upgrade head`,
  этого шага в README нет.
- Прогнал `evals/`: 28 из 30 кейсов, отчёт заявляет 30.

## Блокирующее
1. **README не воспроизводится.** <шаги, лог, что помогло>
2. **Цифры в отчёте не сходятся с прогоном.** <что получилось у меня>

## Существенное
1. **UC-03 не проживается.** Читаю — не могу понять, что происходит при
   пустом ответе модели. В коде обработка есть, в UC её нет.

## Мелочи
- В `compose.yml` нет healthcheck у воркера.
- Диаграмма container не обновлена после появления Redis.

## Что забрал себе
Понравился формат golden dataset: <что именно и почему>.

Последний раздел не для галочки. Рецензия, из которой вы ничего не унесли в свой проект, — потраченный вечер: смотрели, но не увидели.

Как принимать рецензию на себя

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

Молча проигнорировать замечание — единственный вариант, которого быть не должно.