Ревью пул реквестов в подавляющем большинстве случаев больше походит на бюрократию, лишние действия или попытку тотального контроля со стороны руководства. При том, что эта практика используется практически во всех командах и компаниях. Оправдывается она обычно бенефитами и тем, что ревью пул реквестов — вынужденное зло ради вселенского добра. Описанный ниже метод был выведен экспериментально и решает большую часть существующих проблем ревью пул реквестов.
Ложная слепота
Помните тест, в котором нужно было сосчитать количество передач баскетбольного мяча? Если вы не видели, то посмотрите, прежде чем читать дальше.
В 2004 году был сформулирован принцип «ложной слепоты», и этот термин объединяет в себе несколько разнообразных феноменов нашего восприятия. Обычно выделяют два вида ложной слепоты: слепоту невнимания и слепоту к изменениям. Слепота невнимания (перцептивная слепота) подразумевает неготовность нашего мозга воспринимать изменения, которые мы не ожидаем увидеть. Как гориллу в ролике, которую уже окрестили «невидимой гориллой» и даже сайт отдельный для неё сделали. Еще причиной называют рассеянность, которая вызванная необходимостью полностью сконцентрировать внимание. Очевидно, что на себе вы этот феномен можете почувствовать, только если о нем не знаете. И действительно, при повторном эксперименте с другими футболистами и совершенно другой макакой вы ее обязательно заметите, так как ожидаете ее увидеть.
Слепоту к изменениям тоже можно заметить гораздо проще, есть довольно много роликов в интернете на эту тему. Даже National Geographic снял передачу, посвященную этому феномену. В обычных условиях изменение наблюдаемой картины мгновенно обращает на себя внимание. Однако мы можем не замечать изменения, если они совпадают с коротким прерыванием наблюдаемой картинки. Это может быть кратковременное моргание экрана, монтажный стык видео или короткая помеха. В экспериментах по слепоте к изменениям обнаружилось, что почти 70% испытуемых не замечали подмены главного действующего лица, а изменения менее существенных деталей оставались проигнорированными почти в 100% случаев.
Казалось бы, не связанный с программированием термин и совершенно не понятно, как знание об этой слепоте можно применить. Но можно. Разработчик может быть настолько сосредоточен на решении конкретной задачи, которая полностью захватывает его внимание, что не видит очевидных проблем в соседнем методе или решает задачу каким-то странным образом. Отсюда и возникает требование делать ревью кода, идеи парного программирования и концепция работы по технике помидорок, хотя не все могут четко сформулировать, почему эти требования существуют.
Еще в команде всегда найдется такой разработчик, который будет неимоверно крут на фоне всех остальных, и его код, как правило, отсматривается сквозь пальцы. И менее опытные разработчики стесняются делать замечания более опытному товарищу. Конечно же, ревью пул реквестов имеет ещё несколько дополнительных целей, вроде необходимости знать о каком-то куске кода нескольким людям или проверка на очевидность, но это всё лишь приятный и полезный бонус, но точно не основная цель.
Подходы к код-ревью
Есть два разных подхода. Конечно, их больше, но речь о нормальных подходах, а не превращающих ревью в бюрократию с профанацией.
Первый — это открыть пул реквест и промотать его сверху вниз (или в каком-то другом разумном порядке), тщательно его прочитав, что-то выполнив в уме, прочитав тесты и убедившись, что они проверяют код. Потом взять в левую руку Фаулера, в правую — Макконнела и указать на возможные косяки, плохие имена, «тут выделите класс», «заинлайните метод», «тут же N+1 у вас», «хватит мокать тесты», «это не REST», «вы забыли авторизацию», «не надо писать собственный метод, он в стандартной библиотеке уже есть» и всякое такое. Ну, или сказать «молодец». В общем, побыть сильно продвинутым линтером и анализатором кода.
Второй — это прочитать описание задачи, решить её в уме, открыть пул реквест и посмотреть, здраво ли он решает поставленную задачу. И уж потом писать, мол, «ты чего, долбанулся, контроллер и три колонки в базе городить ради этой задачи, elasticsearch же есть», или «уберите эти три поля из формы и добавьте один чекбокс», и «это вредная задача и её вообще не надо было делать такой ценой, уж лучше без фичи вовсе». Как бы побыть человеку напарником в парном программировании, только задним числом. Это существенно дольше, выглядит дублированием усилий в масштабах команды и сильно отвлекает от текущей задачи.
Конечно, справедливо заметить, что обсуждение стратегии должно предшествовать изменениям в коде, а технические неисправности с закрытыми глазами можно исправлять и после. Черт побери, обсуждать глобальные изменения архитектуры после пул реквеста — это значит, что время на пул реквест было потрачено впустую и надо все переделывать. А вот технические ошибки можно бы и самому проверить: отсматривать свои собственные пул реквесты перед тем, как кому-то их показывать, — очень полезное дело. Кроме того, исполнитель потратил сильно больше времени на обдумывание пул реквеста, чем ревьювер. И если считается, что оба разработчика одинаково умны, то вряд ли ревьюверу может прийти какая-то клевая идея, которая не приходила в голову исполнителю, ведь ревьювер потратит на обдумывание существенно меньше времени. Иногда как бы да, но КПД этого процесса больше похож на статистическую погрешность. Но несмотря на это, оба подхода имеют права на жизнь и, согласно опросам, разработчики поделились поровну на два лагеря поддержки первого и второго метода.
Метод наводчика
А решение у проблемы достаточно элегантное. У задачи должен назначаться не один исполнитель, а два.Один делает, другой командует. Прежде чем начать выполнять, командир и исполнитель обсуждают решение, потом командир принимает стратегическое решение, а исполнитель его делает. И затем командир принимает результат.
Ответственность, вроде бы, точно так же распределяется, как и при классическом ревью пул реквеста, только в механике парной работы это не просто формальные правила, а естественные условия работы. Само собой, современные команды состоят сплошь из профессионалов, и считается, что все более или менее равны как по правам, так и по интеллектуальным способностям, поэтому количество ролей «командир» и «исполнитель» у каждого разработчика должно быть приблизительно поровну. В итоге окажется, что в половине случаев каждый разработчик выступает исполнителем, а во второй — командиром. Опять же, «исполнитель» вовсе не означает, что тварь он дрожащая и просто на кнопочки нажимает, вовсе нет. Обсуждения, аргументации и доводы должны быть с обеих сторон. Но окончательное решение должно быть за «командиром».
В качестве аналогии, используется военная тематика, ведь прежде чем жахнуть из гаубицы, нужно знать, куда жахать. И после всех совместных тактических и стратегических рассуждений один мастерски говорит куда, а второй мастерски жахает. Отсюда и название — «метод наводчика».
В дополнение отмечу, что новичкам лучше обучаться на практике, и очень желательно, чтобы практика была своей, а не чужой. Еще учиться лучше всего на ошибках, правда ведь? Метод наводчика предполагает, что наводчиком может быть и молодой разработчик, а опытный будет исполнителем. В этом случае за молодым будет окончательное решение, но это не значит, что опытный должен выключить мозги и тюкать по клавишам, нет. У опытного будет очень сложная задача давать советы, аккуратно возражать и помогать таким образом, чтобы решение действительно было принято молодым наводчиком, а не опытным бойцом. Но с точки зрения опытного, решение должно быть принято правильное, само собой. В методе наводчика это немаловажный бонус, который получается как бы сам собой. Джуны учатся быстрее, правильнее и на своих действиях, а не на чужих. Да и забористые сеньоры тоже учатся правильно обучать молодняк.
Выводы
Резюмируя, вот проблемы, которые решаются методом наводчика:
- Ревьюверам нет дела до пул реквестов соседей по парте, пока этот пул реквест к ним не относится.
- Отвлекаться от текущей задачи не хочется вообще, поэтому ревью пул реквестов становится обузой.
- Ревьювер не может быть слишком строгим, потому как отношения к нему, как к человеку, могут стать хуже.
Проблема сводится к тому, чтобы максимально вовлечь ревьювера в работу этого пул реквеста. И под словом «вовлечь» подразумевается:
- Дать ревьюверу необходимое чувство ответственности за пул реквест.
- Показать исполнителю, что ревьювер — это не формальность или бюрократия, а напарник, который поможет избежать ошибок.
- Наладить правильный, конструктивный диалог между этими двумя.