Ревью кода vs парное программирование

Перевод статьи Udayakumar Rayala «Code Reviews vs Pair Programming».

Я девять лет проработал в командах, члены которых были фанатиками парного программирования. Поэтому я привык работать именно так и ценю преимущества этого подхода.

Но в моем прошлом проекте у нас не было такой роскоши, как парное программирование. Это требовало от нас проведения ревью кода для обеспечения его качества. В этом посте я попытаюсь, основываясь на своем трехмесячном опыте, собрать плюсы и минусы ревью кода по сравнению с парным программированием.

Как это происходит?

В качестве репозитория для исходного кода мы используем GitHub. Предполагается что в master branch всегда попадает только код, готовый идти в продакшн. Каждая история разрабатывается в независимой ветке, затем создается пул-реквест, а после проверки изменения вливаются в master.

Для облегчения ревью кода мы пользуемся git-reflow. Работа над историей обычно включает три стадии:

• Старт

  Вы делаете `git reflow start` в master. Это создает новую ветку с чем-то из master branch. Вы можете работать с этой веткой и при этом вносимые вами изменения не коснутся того, что выпускается в продакшн, потому что туда идут только изменения из master. Наше ПО для обеспечения непрерывной интеграции (TeamCity) было сконфигурировано для запуска билда на каждой созданной ветке. Так что, как только вносятся изменения, сразу запускаются тесты и идет проверка.

• Ревью

  После того, как вы закончили вносить свои изменения и проверили их самостоятельно, вы можете сделать пул-реквест, запустив `git reflow review`. Это создаст пул-реквест (PR) на GitHub. Затем вы можете попросить любого члена вашей команды (или кого-то конкретного) сделать ревью. Они поместят свои предложения в качестве встроенных в PR комментариев. Вы можете обсудить, являются ли какие-то изменения необходимыми. Такие обсуждения обычно проходят между разработчиком и рецензентом. Как только все необходимые изменения внесены, рецензент помечает, что PR может быть смерджен. Для этого он добавляет комментарий LGTM (Looks Good To Me) в PR.

• Доставка

  Теперь вы можете слить свой PR с master branch. У вас могут возникнуть конфликты, если кто-то еще сделал похожие изменения и смерджил их. После успешного слияния вам нужно убедиться, что функционал в master работает, как ожидалось, а все тесты пройдены.

Больше информации о git-reflow можно найти в этих постах:

https://guides.github.com/introduction/flow/

http://scottchacon.com/2011/08/31/github-flow.html

Достоинства

• Отзыв специалиста

  В целом в Agile-команде поощряется универсальность специалистов. Но часто есть преимущество в наличии людей, которые являются экспертами в определенных областях, например, в CSS, базах данных или rails. А конфигурация, которую я описал выше, помогает получить их отзыв о коде перед тем, как он будет смерджен. Это способствует обмену знаниями. И в этом плане ревью кода дает больше возможностей, чем программирование в паре с каждым членом команды. Также это полезно для команд, где джуниоров, которым нужен фидбек по их коду, гораздо больше, чем сеньоров.

• Никто не отбирает у другого клавиатуру

  Парное программирование полезно в качестве способа распространения знаний. Но мне случалось видеть, что люди с большим опытом доминируют в паре. И хотя сначала это помогает делиться знаниями, в итоге это НЕ помогает джуниору приобрести уверенность, нужную для самостоятельной работы. Даже если джуну дают «порулить», он может ощущать некое давление. Ведь в целом пара движется медленнее, поскольку темп задает джуниор.

  Если применяется подход с ревью кода, то джуниоры могут работать над историями самостоятельно. Порой, при необходимости, они могут обращаться за помощью. Также они проводят больше времени за чтением вне основного рабочего времени и не чувствуют себя виноватыми за трату общего (парного) времени. Поначалу доставка может забирать у джуниоров больше времени, но такая организация процесса помогает им приобрести уверенность.

• Подходит распределенным командам

  У меня было много сеансов удаленного парного программирования. И хотя это работало хорошо, у вас часто возникают проблемы с временными зонами и связью. Поскольку ревью кода с пул-реквестами делаются асинхронно, это помогает членам команды работать в удобное для каждого время.

• История сообщений сохраняется

  Комментарии пул-реквестов полезны для каждого, кому впоследствии понадобится узнать, почему что-то было сделано определенным образом.

• Высокая степень сотрудничества

  Общение в ходе ревью кода видно для всей команды. Если у меня есть, что добавить, я могу принять участие в обсуждении. Это случается и при парном программировании, если вся команда сидит в одном месте и разговор может быть услышан всеми. Но в распределенных командах это невозможно.

Недостатки

• Сложно работать над историями, в которых есть зависимости

  Может случиться, что ветки, изменения из которых вам нужны, находятся в процессе разработки. В этом случае у вас не получится получить эти изменения, поскольку они не слиты в master. Это требует от разработчиков, занимающихся зависимыми историями, работать очень близко друг к другу. Также приходится часто делать git merge и git rebase.

• Зазор времени между разработкой и ревью

  Это случается довольно часто, ведь люди заняты работой над собственными историями. Иногда приходится «погоняться» за человеком, чтобы он, наконец, сделал ревью.

• Сложно делать ревью больших изменений

  Если изменений много, то их просмотр требует много времени и сил.

• Задержка фидбека конвейера непрерывной интеграции

  Конвейеры непрерывной интеграции для каждой новой ветки отлично работают только на одном уровне. Если у вас билд второго уровня, который запускает полные тесты многих сервисов, вы не сможете запустить их на всех новых ветках. Поэтому фидбек будет запаздывать.

Заключение

Все это не означает, что нам не следует вообще заниматься парным программированием. Когда вы принимаете новых людей в команду или настраиваете новую кодовую базу, работа в паре может быть полезной. И я считаю, что даже в командах, практикующих парное программирование, может быть полезным делать ревью кода. Главное, чтобы ваши истории были маленькими и вы не пришли к веткам-«долгожителям».

[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]