Как проходит код ревью
Что проверяют
Знаете ли вы, как ревью устроено процессуально, и понимаете ли, что делает его работающим.
Как отвечать
Опишите путь изменения.
1. Подготовка автором. Изменение маленькое, желательно до нескольких сотен строк. Автор сначала перечитывает собственный дифф и убирает мусор. В описании: что и зачем сделано, как проверить, что осталось за рамками.
2. Автоматические проверки. До человека изменение проходит линтер, форматирование, типы, тесты, иногда покрытие. Смысл прямой: люди должны обсуждать смысл, а не пробелы. Спорить о стиле, который может проставить инструмент, значит тратить самое дорогое время.
3. Назначение. Либо владельцы кода по затронутым файлам, либо любой из команды. Обычно требуется одно или два подтверждения.
4. Чтение. Ревьюер смотрит на то, что машина не проверит: подходит ли решение задаче, читается ли код через полгода, обработаны ли краевые случаи и ошибки, нет ли проблем с безопасностью и производительностью, есть ли тесты на новую логику.
5. Замечания. Блокирующее отделяется от вкусового, второе помечается как необязательное. Формулировка про код, а не про человека: вопрос «что будет, если сюда придёт пустой список» работает лучше указания «переделай».
6. Итерации и слияние. Автор отвечает на каждое замечание, спор длиннее трёх сообщений уносится в разговор.
Что делает процесс работающим: размер изменения (главный фактор), скорость ответа (в течение дня, иначе автор уходит на другую задачу), автоматизация формального.
Типичные болезни: ревью становится узким местом, подтверждения ставятся формально не глядя, ревьюер переписывает решение под свой вкус.
Где спотыкаются
Присылают огромные изменения и получают формальное одобрение.
Обсуждают форматирование вручную.
Не отделяют блокирующие замечания от пожеланий.
Считают ревью этапом контроля качества, а не обменом знаниями.