Комментарии 1
Начать надо с того, для чего у вас в команде делается код-ревью. Не для того же, "чтобы было", верно ? Ну так от этого самого "для чего" и нужно выстраивать правила ревью.
Если у вас есть джун на привязи, то у него должен быть назначен наставник который его учит, кормит, мотивирует (и если джун где нагадил - то и убирает тоже!). Тут совершенно очевидно, что джун назначает ревью на своего наставника, и нечего других нормальных людей отвлекать.
Если у вас сделаны рабочие группы (а я не верю в работу толпы разработчиков в 15 голов и выше без внутренней организации) - то рутинные изменения ревьювятся людьми внутри этой рабочей группы (потому что они на дейликах это обсуждали и погружены в контекст)
Если люди делают изменение, которое потенциально затрагивает соседние рабочие группы - то в ревью обязательно включаются соседи. Ибо это - их шанс возразить или что-то улучшить в своих интересах.
Наконец, если делается нетривиальное изменение где нужно конкретное мнение людей имеющих экспертность в этой проблематике - то эти люди зовутся в ревью хэштегами.
В любом случае, я крайне (вот прямо крайне!) не рекомендую рассматривать код-ревью как средство обеспечения качества кода. Ответственность за качество кода несет разработчик, и он обязан его обеспечивать объективными способами (сиречь - писать тесты). Рутинное код-ревью может выполнять функцию синхронизации разработчиков (просматривая по-диагонали чужие MR я продолжаю находиться в курсе того, чем занимаются в других частях большой системы), и должно предотвращать появление в репозитории кода, который другие разработчики могут поддерживать и сопровождать только через боль и страдания.
Также я крайне не рекомендую на код-ревью выяснять как должно быть реализовано решение. Это надо делать во время груминга задач. Иначе получается глупость - мы сначала тратим время на решение, потом на ревью устраиваем срач по поводу того, как надо было, потом делаем еще раз. Это, наверное, хорошо для борьбы с безработицей или повышения валового внутреннего продукта (он растет даже если делать и более бессмысленные вещи: например рыть и засыпать яму на одном и том же месте) - но для дела это не годится!
Помимо этого, я крайне не рекомендую устраивать полемику внутри код-ревью. Написали замечание, а вы не согласны (или не понимаете) ? Сделайте движение ногами (в офисе) или мышкой (на удаленке) - и напрямую поговорите с человеком. Потом отпишите в тред ваши договоренности.
Для выработки общих правил и устраивания срача - есть ретро. Не хватает ретро - добавьте архитектурных сессий. Желательно в конце рабочего дня, чтобы особо упертые могли сидеть и меж собой сраться пока силы не кончатся...
Код-ревью и Рингельман