Мысли про Pull Request Assignee
Внимательно подбирай аудиторию
В завершении записи про создание pull request’а, я вскользь упомянул assignee
Назначь в assignee заинтересованных коллег (будь то отдельные юзернеймы, целые команды, или только ответственные за ревью)
Будто бы это настолько легко и настолько малозначительно…
Серия записей про code review:
You are Reviewer Zero
Нулевым ревьювером является сам автор pull request’а. Конечно, ничто не мешает забить и переключиться на другую задачу после того, как передал эстафету коллегам, но просмотр уже знакомого кода в другом окружении (UI code review вместо UI code editor’а) или спустя некоторое время (когда все «очевидности» забылись) поможет самостоятельно заметить опечатку или какой-нибудь странный момент
Я иногда делаю ещё так - после публикации своего PR я сам же ему делаю Review (в Github можно прокомментировать свой PR, но без Approve). Это позволяет добавить комментарии/контекст конкретно к тому коду, которого это касается
— хороший комментарий к прошлой записи
Особенно удобно это сделать в черновом pull request’е, который вроде как уже создан и запустил свои проверки на CI, но ещё не сообщил о своём существовании code owner’ам
Кому смотреть
В небольших проектах с плотной командой, вопрос «кому кинуть на ревью» решается сам собой — ты либо кидаешь всем (потому что вас немного), либо ты знаешь ответственную за ту или иную часть кода и кидаешь ей
В более… динамических проектах и командах, из-за размеров и слабой связи, ситуация может быть менее простой. Зачастую, это решается указанием в уже упомянутых code owner’ах либо «владельцев мнений» (тимлиды/техлиды/сеньоры/помидоры), либо целых команд. Это влечёт за собой одну из двух проблем: «много нас, а он один» и «много вас, а я один»
Много нас, а он один
Команда в ревьюверах порождает риск того, что каждый участник команды посчитает, что просмотр твоего pull request’а — чужая задача. Наличие «дежурных»/«oncall» в команде не спасёт — если pull request был создан вечером пятницы, когда я был дежурным, то в понедельник я буду думать «теперь это проблема сегодняшней дежурной Лены» и забить. Лена, в свою очередь, тоже может справедливо забить — pull request же пятничный, а в пятницу дежурила не она
Плюс, новички в команде могут стесняться комментировать — вдруг что-то не заметят или зададут «глупый» вопрос. А если в ревьюверах вся остальная команда, то можно затаиться и переждать
Команда в assignee может иметь и противоположный эффект, когда все-все-все спешат оставить комментарий, не особо вдаваясь в подробности1. В теории, автор pull request’а может вложить время и силы на ответ всем "зевакам", но это сложно, изнуряет, и может требовать оправданий начальству, если оно считает что «твоя задача — решать проблемы с кодом, а не учить джунов в других командах»
Много вас, а я один
Наличие кого-то, через кого будут проходить все pull request’ы, конечно, имеет свои плюсы, например, более консистентный стиль и высокий шанс заметить конфликт с неявным допущением в проекте
Но глупо ожидать (или требовать), что один человек будет внимательно пропускать через себя весь контекст с той же скоростью, с которой пишет код вся остальная команда вместе взятая. В треугольнике «много/быстро/внимательно» все три выбрать нельзя. Даже два не всегда получается…
Я не знаю, как однозначно решить обе проблемы. Но уверен, что:
- на каждый отдельный pull request лучше назначать не всю команду, а определённых людей, даже если единственный их вклад будет «переназначить на более подходящего человека»
- очень важно избегать образование bottleneck персоны, которая недолго продержится под давлением со стороны начальства и коллег
- не только лиды/сеньоры должны смотреть pull request’ы, но и джуны. Иначе без джуновского «что здесь происходит?» всё улетит в стратосферу на абстракциях, а упростить код в момент code review намного проще, чем после него
После этого отступления, теперь точно можно говорить о процессе с точки зрения ревьюверов