📖 Процесс ревью кода структурно порочен. Вот, как его исправить

На ревью слишком много времени тратится на переключение контекста и ожидание автора и ревьера:

После создания PR’а, мы ждём, когда ревьюер закончит свои дела и изучит код автора.
Если необходимо внести изменения, то приходится ждать, когда вернется автор и внесет изменения, ведь скорее всего он уже занимается следующей задачей.
И всё повторяется снова до тех пор, пока качество не удовлетворит ревьюера.

Часто ревьюер — более опытный коллега и он знает, какие подходы лучше использовать и как нужно делать. Высока вероятность, что автору будет необходимо внести изменения, так как его видение отличается от видения ревьюера.

Поэтому нужно начинать ревью еще до того как PR готов, чтобы вероятность переделывания задачи была как можно ниже. Чем раньше произойдёт ревью — тем меньше будут отличаться видения, меньше изменений будет необходимо внести, и тем быстрее работа будет завершена.

К тому же, если весь код уже готов и работает, и автор потратил много часов на его реализацию, какова вероятность, что вы попросите его вносить изменения? Слишком жалко потраченного времени.

Как решить?

Обсудить план решения с более опытным коллегой, чтобы в дальнейшем пришлось меньше переделывать
Произвести первое ревью, когда изменения готовы на 30-50%. Скорее всего ваш план не сработал на 100%, поэтому ваши видения с ревьюером снова разошлись, поэтому нужно снова провести ревью. Здесь необходимо смотреть на концепцию решения задачи и не придираться к небольшим ошибкам.
Чтобы сократить время ожидания ревьера можно ввести роль дежурного по ревью. Как только появляется PR, ревьер сразу же приступает к ревью. В свободное время ревьюер занимается низкоприоритетными задачами: техническим долгом или неважными багами.

Конечно, подход с дежурным сработает не в любой команде. Если проект и команда очень большие, то такой подход вряд ли подойдёт, ведь ни один человек в команде не будет полностью разбираться как реализован продукт и просто не сможет провести качественное ревью.