Формальное ревью узнаётся сразу: лайк через пять минут и комментарий «LGTM» на диффе в восемьсот строк. Потом в проде ловят то, что глаз мог бы поймать за четверть часа нормального чтения. Я сам так грешил, когда очередь PR давила сильнее совести и хотелось просто «разгрести инбокс».
Хорошее ревью начинается с вопроса «что здесь должно измениться для пользователя или системы?». Если из описания это не ясно — я сначала прошу переписать summary и контекст, а не лезу в стиль именования. Иначе спорим про пробелы и импорты, а мимо проходит смена контракта API или тихая правка миграции.
На практике я читаю дифф в два прохода. Первый — поведение и риски: гонки, идемпотентность, миграции, откат, права доступа, что будет при частичном фейле. Второй — читаемость, имена, мелочи. Если смешать проходы, мозг залипает на нейминге и пропускает то, из-за чего ночью разбудят дежурного.
Два прохода по диффу
Комментарии стараюсь писать как предложение, а не как приговор. «Тут при пустом списке уйдём в 500 — давай явный 404?» работает лучше, чем «это неправильно». Люди защищают код, когда чувствуют атаку; им проще править, когда видят совместный поиск дыр, а не экзамен на профпригодность. Полезно договориться о SLA ревью: сколько часов до первой реакции и что делать с зависшими PR. Иначе навык упирается в очередь, а не в качество. Лучше честно сказать «сегодня не успею», чем поставить пустой апрув.
Не всё стоит блочить. Стиль без договорённости в линтере — шум, который учит авторов игнорировать ревью. Блокер для меня: потеря данных, дыра в доступе, ломающий контракт без миграционного плана, миграция без отката, тихий change в платёжной логике. Остальное можно оставить nit и не держать автора в заложниках до вечера.
Что реально блокер
Ещё навык — вовремя сказать «я этого куска не понимаю, нужен второй ревьюер». Притворяться экспертом по платёжному модулю, который видишь раз в год, дорого обходится команде. Лучше честно сузить зону ответственности и позвать человека, у которого уже есть шрамы на этой теме. Слежу за тоном в конце дня: усталые комментарии резче, чем задумано. Если раздражён — откладываю ревью или перечитываю черновик через десять минут. Дешёвый способ не портить отношения из-за скобок.
И да, ревью — двусторонняя вещь. Если автор кидает гигантский PR без разбиения и без описания, я прошу разрезать. Качество ревью падает нелинейно после пары сотен осмысленных строк; притворяться, что это не так, бессмысленно. Маленькие PR — не бюрократия, а способ получить настоящие глаза на код.
Отдельно учу себя хвалить конкретное: удачный тест, ясный откат, хорошее логирование. Иначе ревью превращается в поток претензий, и люди начинают бояться открывать PR — а это уже хуже отдельных багов.