Незгоди - нормальна частина рев'ю. Проблема не в них, а в тому, що вони тягнуться днями в коментарях і псують стосунки.
Як розв'язувати незгоду:
- розділити факти й смак. Баг, вразливість, порушення домовленостей команди - аргумент. «Я б написав інакше» - ні, якщо рішення автора теж коректне;
- спиратися на спільні правила, а не на авторитет: стайлгайд, архітектурні рішення (ADR), домовленості команди. Якщо правила немає - це привід його створити, а не виграти суперечку;
- перейти в розмову: після двох-трьох раундів коментарів 10 хвилин дзвінка вирішують більше, ніж ще десять повідомлень. Підсумок - записати в PR;
- ескалація до техліда чи ширшого обговорення, якщо згоди немає, - це нормальний механізм, а не поразка;
- «не блокує, але»: рецензент може погодитися злити зараз і створити задачу на покращення - якщо проблема не критична.
Принцип рецензента: схвалювати зміну, яка покращує стан кодової бази, навіть якщо вона не ідеальна. Вимога досконалості зупиняє розробку.
Як рев'ю стає вузьким місцем:
- PR чекають рев'ю по кілька днів, автори перемикаються між задачами й втрачають контекст;
- рев'ю робить одна людина;
- великі PR, які ніхто не хоче брати.
Що допомагає:
- домовленість про швидкість відгуку: перша реакція протягом робочого дня; не обов'язково повне рев'ю, але хоча б «подивлюсь після обіду»;
- рев'ю - пріоритетна робота, а не те, що роблять «коли буде час»: незлитий PR - незавершена робота;
- розподіл рев'юерів - автоматичне призначення команді за CODEOWNERS чи round-robin, щоб навантаження не падало на одних і тих самих;
- маленькі PR - їх рев'юють швидко;
- автоматика знімає з людей стиль і очевидні помилки;
- вимірювати час до першого відгуку й до злиття - без цифр проблема помітна лише відчуттям;
- парне програмування для складних змін - рев'ю відбувається під час написання.
Докладніше в документації: Google: як працювати з запереченнями в рев'ю
