Когда парное программирование полезно и эффективно? Когда это не так?

Что такое парное программирование?

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

водитель, инженер-программист «за рулем», кодирующий функцию.
навигатор, инженер-программист, наблюдающий.

В большинстве случаев эта форма парного программирования сводится к одному из четырех различных сценариев:

  • Старший инженер-программист за рулем, старший инженер-программист за рулем
  • Старший инженер-программист за рулем, младший инженер-программист за рулем
  • Младший инженер-программист за рулем, старший инженер-программист за рулем
  • Младший инженер-программист за рулем, младший инженер-программист за рулем

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

Старший водитель, Старший штурман

Из четырех этот сценарий обеспечивает наименьшую ценность. Но не ни один.

Я всегда считал, что основной целью парного программирования является обучение, а не продуктивность. Есть старый анекдот о разработке программного обеспечения, который я слышал много раз:

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

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

Старший водитель, младший штурман

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

Это действительно отнимает время у старшего инженера-программиста. Ответы на вопросы более свежих и предоставление объяснений в режиме реального времени замедлят развитие функции. Они также не могут воспользоваться преимуществами быстрого слияния запросов на вытягивание, потому что они, вероятно, захотят, чтобы кто-то, кто не новичок, проверил его.

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

Младший водитель, Старший штурман

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

Этот сценарий отлично подходит для превращения младших инженеров-программистов в старших инженеров-программистов. Когда дело доходит до того, чтобы стать старшим инженером-программистом, получение отзывов от других старших инженеров-программистов является важной частью уравнения.

Младший водитель, Младший штурман

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

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

Кроме того, на более откровенной ноте, этот сценарий просто забавен.

Спасибо, что читаете!