Pair Programming

Хорошее, плохое, и отвратительное.

Когда я начинал на своей первой работе в качестве разработчика, то для меня существовал только один способ программирования: опустить голову и писать код. Время от времени я сотрудничал с членами команды, но, как правило, программирование выполнялось самостоятельно на моей собственной машине.

Затем я узнал о компании, которая похвасталась тем, что она занимается только 100% «Парным программированием». Что же такое парное программирование? Парное программирование — это когда два человека сидят за одной машиной и решают вместе одну и ту же задачу. Это похоже на сотрудничество с командой, о котором я говорил ранее, но вместо того, чтобы данный подход был исключением, это было нормой.

Позже я узнал, что утверждение о парном программировании было не точным, потому что эта компания не просто занималась парным программированием, она также практиковала то, что называется моббингом. Моббинг — это то же самое, что и парное, за исключением того, что вместо двух человек, работающих вместе над одной задачей, у вас будет более трех людей, . Ревью кода, как правило, в данном подходе тоже существовало, однако к нему относились с меньшим приоритетом.

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

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

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

Хорошее

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

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

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

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

Плохое

Не все так гладко. С точки зрения разработчика, у парного программирования есть свои недостатки. Одним из них является отсутствие своей собственной кодовой базы. Так как в команде вы часто меняете партнеров, это дает вам ощущения того, что у вас нету своей собственной «домашней базы».

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

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

Отвратительное

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

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

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

Вердикт

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

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

Последняя рекомендация также подразумевает, что парное программирование — это не то, чем вы занимаетесь весь день. Наилучшим решением было бы скооперироваться тогда, когда это действительно нужно. Может быть, вам следует создать пару утром, разойтись, а затем снова встретиться в конце дня.

В конечном итоге, парное программирование— это хорошо, и его следует поощрять. Однако все необходимо в меру, иначе негативы могут затмевать позитивы.

Translated: Justin Travis Waith-Mair