Обычно говоря о код ревью, мы подразумеваем процесс, когда код отправляется от автора фичи к другому разработчику для проверки его правильности. Однако помимо этого, код ревью выполняет ещё одну важную функцию - распространение знаний о коде. Если у вас в команде код проходит стадию Code Review, то по крайней мере несколько человек знают о внесённых изменениях.
Код ревью - определенно хорошая практика, которая может предотвратить попадание ошибок в прод и улучшить кодовую базу. Но в то же время плохо настроенный процесс код ревью может значительно замедлить разработку. Ваш Pull Request, может ожидать несколько дней, а то и недель, пока ваш коллега найдёт время, чтобы взглянуть на него. Через неделю, ваш дружелюбный коллега оставит несколько комментариев, после чего вам потребуется ещё пара дней на исправления. Но в то же время, ваш менеджер сообщит вам, что релиз придётся перенести, потому что ваша задача не выполнена?!?!?!
И это ещё не всё! Бывают случаи, когда код ревью является сильнейшим демотиватором. Это особенно заметно, когда ревьюер, придираясь к каждой строчке, показывает своё превосходство, после чего ваши отношения начинают портиться, и вы старательно его избегаете.
Поэтому очень важно не только проводить код ревью, но и проводить его правильно.
Как правильно проводить код ревью:
Ещё по теме:
Небольшой совет для ревьюеров - Код ревью лучше делать, когда ты не находишься в контексте другой задачи, так как переключение контекста является довольно время и энерго затратной операцией. Иными словами лучше делать код ревью:
- после завершения задачи
- утром
- после обеда
- после завершения дейли-митинга.