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

> Как разобрать чужую работу так, чтобы это было полезно автору: запуск вместо чтения, порог значимости, что замечанием не является

_Источник: https://sii.sergeivolchkov.ru/materials/labs/peer-review_



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

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

## Запуск вместо чтения [#запуск-вместо-чтения]

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

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

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

| Роль             | Что делает измеримого                                                                                                                                                    |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Product / VO     | Берёт use case и пытается разыграть по нему сценарий. Не смог без вопросов к автору — [проживаемость](/materials/use-cases/writing) не выполнена, и это проверяемый факт |
| AI Engineer      | Берёт цифры из отчёта и воспроизводит их на том же наборе. Не сошлось — это находка, а не придирка                                                                       |
| Delivery         | Разворачивает по README на чистой машине. Считает шаги, которых в README нет                                                                                             |
| Quality & Safety | Гоняет чужие evals и чужой threat model: какие атаки не покрыты, какие метрики не воспроизводятся                                                                        |

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

## Что замечанием не является [#что-замечанием-не-является]

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

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

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

## Порог значимости [#порог-значимости]

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

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

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

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

## Формат [#формат]

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

```markdown title="docs/reviews/review-team-04.md"
# Рецензия на проект «Тренажёр к экзамену», команда 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: <что именно и почему>.
```

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

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

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

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