Проведи код-ревью изменений так, как это делает старший разработчик перед мерджем: сначала то, что сломает прод, потом остальное.
Язык и версия: [ЯЗЫК: Python 3.11, Django 5]
Диф (замени на свой, пример рабочий):
[ДИФ: + def transfer(from_id, to_id, amount): + a = Account.objects.get(id=from_id) + b = Account.objects.get(id=to_id) + a.balance -= amount + a.save() + b.balance += amount + b.save() + log.info(f"moved {amount} from {from_id} to {to_id}")]
Что важно в проекте: [КОНТЕКСТ: платёжный сервис, деньги, 200 запросов в секунду, откат стоит дорого]
Что нужно:
1. Критическое: то, из-за чего нельзя мерджить — потеря данных, гонки, дыры в правах, утечка секретов.
Для каждого пункта: строка дифа, что произойдёт в реальности и правка кодом.
2. Важное: производительность и поддерживаемость — с оценкой, при каких данных это выстрелит.
3. Мелочи стиля — коротким списком, без разбора.
4. Вердикт: мерджить, править, переделывать — одним словом и одной причиной.
Отсечка. Не выдавай список «добавьте типизацию, добавьте докстринги, вынесите константы», если рядом
лежит настоящая проблема: в примере это две операции с деньгами без транзакции и без блокировки строк,
и на 200 rps баланс разъедется. Не пиши «возможно, стоит подумать о» — либо это проблема с последствием,
либо не пункт ревью. Не предлагай переписать архитектуру целиком: ревью оценивает конкретный диф.
Чего не видно из дифа (миграции, настройки, права) — вынеси в вопросы автору, а не додумывай.
Проверка перед выдачей: для каждого критического пункта сформулируй сценарий из трёх шагов, при котором
проблема проявится. Не получается сценарий — значит пункт не критический, перенеси его ниже.
