А зачем вообще тратить время на code review?

Продолжу тему code review ответом на ещё один вопрос подписчика А будет рассказ про цели ревью? Используете ли его в основном для распространения знаний, синхронизации по архитектуре или поиска багов? На эту тему тоже холивары бывают.) Мне доводилось проводить code review с самыми разными целями.

Коллективное владение кодом

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

Я помню лихие времена своих первых двух лет в Яндексе, когда у нас ещё не было обязательного ревью всех коммитов, — разработчики сразу заливали исправления со словами «Я исправил». И никто не знал, а как именно это было сделано. А потом в коде обнаруживались сюрпризы 😆

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

Передача знаний

Этим я очень много занимался в Яндекс Еде. Когда я только туда пришёл, Еда переезжала с PHP на C. У нас была группа из трёх экспертов по С, которые смотрели все PR'ы на этом языке. Мы не столько вникали в суть решаемой задачи, сколько доносили идиоматические способы программировать на C++ с использованием userver.

Сюда же идёт вся моя многочисленная практика онбордингов разработчиков в Еде. Например, я руководил техническим буткемпом в userver в Еде. И там мы использовали code review как способ показать, как у нас принято решать те или иные типовые задачи. Я разработал специальную задачу, которую выполнял каждый новый разработчик в Еде, и потом на code review мы поясняли: что он сразу сделал как принято, а что надо сделать иначе.

Поддержание архитектурной целостности

Отчасти перекликается с первым пунктом, но цель не в том, чтобы все знали, как всё устроено, а в том, чтобы не плодить велосипеды. В моей второй команде в Яндексе мы делали большой С проект с нуля. У нас собралось 5 сильных и умных разработчиков на С, и у каждого было своё мнение, как надо писать код «правильно». Мы устраивали жаркие споры в PR'ах, когда кто-то делал свою часть по-своему. Много копий тогда было сломано, но, в конце концов, мы более или менее находили общий для всех подход, который потом уже применяли все.

Поиск дурацких багов

Баги должны ловить тесты, а не люди на ревью. Тем не менее, нет-нет, да и вылезет что-то, что стреляет раз в тысячелетие, тестами не ловится, но бьёт очень больно. Такие баги часто случаются из-за незнания каких внутренних особенностей или простой невнимательности. И свежий взгляд со стороны очень полезен, чтобы их поймать.

Так что поиск багов — это точно не главная цель ревью, но полезная фича.

С этим хорошо справляется наш процесс review as a service в Pangolin. Я уже не раз получал подобные комментарии к своим PR'ам и восклицал: «Как хоть я сам-то не заметил?!» В этом как раз и есть польза внешнего взгляда.

Для каких целей вы проводите code review у себя?

Напоминаю, что вы можете обратиться ко мне за консультацией через сервис GetMentor. Можно провести разовую консультацию или пойти в регулярную работу (сейчас есть одно место из двух). Ко мне обращаются люди с такими запросами: — подготовка к собеседованию в HFT компанию — мок-интервью по алгоритмам, чтобы оценить текущий уровень и определить пробелы — code review многопоточного кода на C++

Отзывы о проведённых встречах в отдельном канале.

В этом посте были ссылки, но мы их удалили по правилам Сетки