2022-06-15 11:01:00
Ревью пулл реквеста нужно глобально только по двум причинам: с целью улучшения техники или стратегии. Техника — это когда Фаулер доволен и тесты быстры и зелены, а стратегия — это когда код готов к глобальным изменениям, неожиданным капризам клиентов и внезапным пиковым нагрузкам не там, где подстелили соломки.
Логично, что обсуждение стратегии должно предшествовать изменениям в коде, а технические неисправности с закрытыми глазами можно исправлять и после. Черт побери, обсуждать глобальные изменения архитектуры после пулл реквеста — это значит, что время на пулл реквест было потрачено впустую и надо все переделывать. А вот технические ошибки можно бы и самому проверить — отсматривать свои собственные пулл реквесты перед тем, как кому-то их показывать, очень полезное дело.
Ещё одна страшная проблема: исполнитель потратил сильно больше времени на обдумывание пулл реквеста, чем ревьювер. И если считается, что оба разработчика одинаково умны, то вряд ли ревьюверу может прийти какая-то клевая идея, которая не приходила в голову исполнителю. Иногда как бы да, но КПД этого процесса больше похоже на статистическую погрешность.
Конечно же, ревью пулл реквестов имеет ещё несколько дополнительных целей, вроде необходимости знать об каком-то коде нескольким людям, или проверка очевидности кода, но это лишь приятный и полезный бонус, но точно не основная цель.
А решение у проблемы достаточно элегантное. У задачи должно назначаеться не один исполнитель, а два. Один делает, другой командует. Прежде чем начать выполнять, командир и исполнитель обсуждают решение, командир принимает стратегическое решение, исполнитель его делает, командир принимает. Ответственность, вроде бы, точно так же распределяется, как и при классическом ревью пулл реквеста, только в механике парной работы это не просто формальные правила, а естественные условия работы.
Конечно же, современные команды состоят сплошь из профессионалов и считается, что все более-менее равны как по правам, так и по интеллектуальным способностям, поэтому количество ролей «командир» и «исполнитель» у каждого разработчика должно выходить приблизительно поровну. В итоге окажется, что в половине случаев каждый разработчик выступает исполнителем, а во второй — командиром.
Опять же, «исполнитель» вовсе не означает, что тварь он дрожащая и просто на кнопочки нажимает, вовсе нет. Обсуждения, аргументации и доводы должны быть с обеих сторон. Но окончательное решение должно быть за командиром.
408 views08:01
Э
