Я был частью первой проектной группы в Pixo, которая включила парное программирование как явную часть устава нашей команды. Мы вчетвером нырнули в это. Я помню, как захватывающе было читать о преимуществах и планировать собственное пространство для проекта со всеми необходимыми мониторами и периферийными устройствами, чтобы все работало. Мы испытали на себе все взлеты и падения: было так здорово постоянно общаться и планировать в одной команде! Было так утомительно так много говорить. Было так здорово постоянно обмениваться идеями! Иногда казалось, что нужно так много работать, чтобы написать несколько строк кода.

Как я тогда относился к парному программированию ...

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

Вот что я написал тогда:

Обычное парное программирование:

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

Эта первоначальная проектная группа столкнулась с рядом проблем. Помимо того, что мы привыкли к спариванию, мы изучали новые технологии. У нас было несколько смен в команде, и все это вдобавок к обычным трудностям проекта. Мы столкнулись с проблемами, связанными с резкой разницей в навыках партнеров. Мы боролись с длительной усталостью партнера. Нам нужно было выяснить, когда спаривание было эффективным, а когда - пустой тратой времени. Мы вместе занимались доской и программировали независимо. Мы часами мучились из-за тонких проектных решений и зависимостей модулей (и поняли, насколько важно обдумывать это заранее).

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

…и сейчас

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

  • Практически то же самое.
  • Действительно.

Все в моем первом списке - это фундаментальное преимущество тесного сотрудничества с другим разработчиком и разделения ответственности за результат. Это повышает качество и создает команду. Во всяком случае, я заметил, что список преимуществ все больше и больше увеличивается по мере того, как я продолжаю сотрудничать с более опытными партнерами.

Я хотел бы услышать мнение других разработчиков. Какие преимущества (или недостатки!) Вы испытали при парном программировании? Что-то я здесь пропустил? Если вы опытный парный программист, изменилось ли ваше мнение со временем?