Автор: Sergey Teplyakov

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

До последнего времени у меня не было личного опыта парного программирования, поэтому мое мнение было сугубо теоретическим. За последние полгода у меня появился какой-то опыт, и именно им и хотелось бы поделиться.

PairProgramming

Итак, начнем с проблем.

Проблема #1. Психологическая и рабочая несовместимость

Главная проблема в этой затее в том, что нельзя (ИМХО) просто взять двух членов команды, приковать их наручником к клавиатуре и получить хороший код на выходе. У разных людей разные мыслительные процессы и разные подходы к работе. Для кого-то нормально набросать кучку другую кода, увидеть результат, потом его причесать. Для другого нужно порисовать на листочке бумаге, написать тест, потом закодить все одним махом. Для третьего важно что-то еще.

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

Проблема #2. Несоответствие в опыте

Эффективное парное программирование подразумевает равный опыт. Это не работа вида подмастерье-мастер. Здесь должна быть пара пусть и с разным, но с соразмеряемым уровнем. Да и опыт в предметной области и в конкретной технологии должны быть соизмеримы.

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

Проблема #3. Парная работа не подходит для любых задач

Есть виды деятельности, которые просто не имеет смысла выполнять совместно. Когда нужно допилить десяток граничных условий или причесать код для соответствия стилю программирования, то делать это в 4 руки это просто waste of time.

Проблема #4. Парная работа утомляет

Pair programming is tiring but satisfying. Most programmers cant pair for more than five or six hours in a day. Kent Beck

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

Проблема #5. Парная работа требует погружения в контекст

Rotate pairs frequently. Some teams report good results obeying a timer that tells them to shift partners every sixty minutes (every thirty minutes when solving difficult problems). Kent Beck

Любая сложная работа требует времени на погружение в контекст и, опять же, я просто не представляю, как можно тасовать пары каждый час. Каждый день? Возможно. Если пара работает над смежными задачами и совместно решает вопросы интеграции? Без вопросов. Но меняться по принципу каждый с каждым внутри команды каждый час? Звучит очень сомнительно.

Когда парное программирование работает?

Есть ряд областей, в которых парное программирование применяется очень давно. Первые две это отладка и проектирование.

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

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

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

Слабать совместный кусок, который связывает куски, над которыми два человека работали изолировано просто идеальное для парной работы.

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

З.Ы. А у кого какой опыт парного программирования? Делитесь, плз!

Помогла статья? Оцените её!
0 из 5. Общее количество голосов - 0
 

You have no rights to post comments

Дмитрий Крикунов

Публикую статьи, обучающие курсы и новости по программированию: алгоритмам, языкам (С++, Java), параллельному программированию, паттернам и библиотекам (Qt, boost).