Чтобы решить эту проблему и устранить все эти задержки, в компании решили полностью избавиться от рецензирования кода в Gerrit. Вместо него для внесения правок в систему нужно было использовать парное программирование. Благодаря этому программисты сократили время на оценку кода с недель до нескольких часов.
Элизабет Хендриксон тем не менее отмечает, что рецензирование кода отлично работает во многих организациях. Однако оно требует наличия культуры: анализ кода должен цениться так же высоко, как и его создание. Когда такой культуры еще нет, парное программирование может служить важным промежуточным шагом.
Оценка эффективности pull request процессов[139] Поскольку рецензирование кода — важное средство контроля, мы должны уметь определять, эффективно оно или нет. Один метод заключается в том, чтобы рассмотреть сбои и оценить, можно ли что-то изменить в процессе рецензирования, чтобы этих сбоев можно было избежать.
Другой способ был предложен Райаном Томайко, директором по информационным технологиям и сооснователем GitHub, а также одним из авторов идеи запросов на внесение изменений. Когда его попросили описать разницу между хорошим запросом на внесение изменений и плохим, он сказал, что результаты не имеют к этому никакого отношения. У плохого запроса недостаточно контекста для читателя и нет описания, что эта правка должна делать, например, если сопроводительный текст выглядит как «Исправление проблемы #3616 и #3841[140]».
Этот реальный внутренний запрос организации GitHub Райан Томайко раскритиковал: «Скорее всего, его написал один из новых сотрудников нашей компании. Во-первых, в нем не было указано ни одного инженера. Как минимум программист должен указать своего наставника или специалиста в той области, к которой относится правка, чтобы рецензию провел компетентный человек. Но вдобавок нет никакого пояснения, что это за изменение, почему оно важно или как размышлял его автор».
С другой стороны, на вопрос о хорошем запросе, отражающем эффективный процесс рецензирования, Томайко быстро перечислил важнейшие элементы: должно быть достаточно деталей о том, зачем нужно это изменение, как оно было проделано, а также его возможные риски и меры противодействия этим рискам».
Райан Томайко также обращает внимание на хороший анализ вносимого изменения в контексте запроса: часто в нем акцентируются дополнительные риски, идеи по более подходящим способам внедрения изменений и по смягчению возможных рисков и так далее. И если во время развертывания происходит что-то плохое или неожиданное, информация добавляется в запрос вместе со ссылкой на проблему. Обсуждение проходит без поиска виноватых; вместо него проходит открытый и непредвзятый разговор о том, как предотвратить такие проблемы в будущем.