Зачем code review

Может я один такой, но меня раздражают шутки вроде

Ну, то есть сама шутка ок — i-know-that-feel.png, #relatable, всё такое. Но в ней несколько примеров негативного поведения что авторов кода, что ревьюверов:

• поверхностные комментарии;
• огромные патчи;
• нехватка контекста;
• чтение «по диагонали»

Так что если проблемы с code review настолько повсеместны, то на них надо не только показывать пальцем, но и как-то исправлять. Сделать это можно либо внешними требованиями/ограничениями, либо внутренней мотивацией

Требовать «будь лучше» — глупо. Автоматически рубить code review по метрикам — не вариант, потому что «понятность» не измерить скриптом. Так что «улучшить code review внешними требованиями/ограничениями» отпадает

Повлиять на внутреннюю мотивацию можно собственным примером, но спустя годы попыток, это кажется слишком медленным и неособо надёжным. Может, собственный пример будет быстрее донести словами

Серия записей про code review:

1. Зачем?
2. Создание Pull Request’а
3. Мысли про Pull Request Assignee
4. Code Review & Response

Время и место

Я работал только в довольно зрелых продуктовых компаниях. Когда компания годами работает над продуктом, вкладывание времени и усилий в code review оправдано не только «ну, это правильно», но и упрощением поддержки в долгосрочной перспективе

Совсем молодые продукты, у которых этой самой долгосрочной перспективы может и не наступить, рискуют тем, что после всех review останется только "правильный", но никому не нужный код

Как обстоят дела с клиентской работой (аутсорс/аутстафф) я не знаю. С одной стороны, если клиент вернётся за доработками год-другой, прошлые code review помогут быстрее вспомнить/узнать кодовую базу. С другой — клиент может никогда не вернуться

Так что code review может быть бесполезным (или вообще вредным) на твоём месте работы. Или он был таковым на прошлом месте работы твоей новой коллеги…

Мотивация

Окей, допустим ты работаешь в подходящей команде, в подходящее время, и тебе хочется лучше писать и комментировать Pull Request’ы. Чтобы знать направление для улучшений, надо понимать, какова цель code review

Итак, зачем проводить code review?

Мне сказали, что у нас так принято

«Так исторически сложилось» — плохая дорога к улучшениям, потому что она ведёт туда же, откуда началась. И даже рассказать будет не о чем (если тебе не нравятся истории, в которых ничего не происходит)

Чтобы идиоты ничего не поломали в моём идеальном проекте

Эти «идиоты» открыли PR, потому что им надо что-то исправить или что-то улучшить. Если твой идеальный проект не горит только за счёт gatekeeping’а с твоей стороны, то лучше направь усилия в написание тестов и настройку линтера

Чтобы словить то, что тяжело или вообще нельзя покрыть тестами

Теплее… Но «хранителям знаний» быстро надоест высматривать сотни и тысячи строк кода в поисках одних и тех же проблем, с которыми сталкиваются коллеги, незнакомые с репозиторием

Из «заиметь побольше рутинной работы» получается плохая цель. Хотелось бы, чтобы оно само

Но новички репозитория (именно репозитория — у них может быть огромный опыт разработки в принципе) не знают, что {placeholder} вызовет проблемы. А ветераны уже так часто натыкались на {placeholder}, что инстинктивно его избегают

Поэтому, чтобы оно само, авторы и ревьюверы должны обмениваться внутренним пониманием проекта:

• авторы явно и неявно указывают на странности в существующем коде. Например, что для достижения простой цели надо сделать кучу ручной работы
• ревьюверы делятся базовыми предположениями, на которых работает проект, вроде «мы на ошибки возвращаем код 200 и объект с ключём error из-за решения, принятого десять лет назад и вокруг которого написано много кода»

Так что you need two to tango have a good code review

Продолжение: Создание Pull Request’а