Парное программирование является одной из практик XP. Эта практика воплощает экстремальную (преувеличенную) идею Code Review. Если ревью позволяет улучшить качество кода, то давайте делать его постоянно, во время рефакторинга и написания нового кода.

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

Как это делать?


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

Исследования


Самый большой скепсис вызывает вопрос: Не будет ли разработка идти медленней, когда два программиста занимаются одной задачей?

Исследования показывают, что работа в паре делает либо с такой же скоростью, как и по одиночке, либо немного (15%) медленнее. Зато код получается намного качественней, содержит меньше ошибок (60%) и технических долгов.

Результаты исследований, приведенных ниже, очень схожи с моими наблюдениями в повседневной работе. К тому же я, как преподаватель в ЮУрГУ, начал давать парное программирование с самого начала своего курса. Мои результаты будут в конце учебного года, а пока подборка публичных исследований на тему:


Бонусы от парного программирования
  1. Обмен опытом: Часто бывает, что сидя в паре вы узнаете про пару новых горячих клавиш, интересные утилиты для ускорения работы. В любом случае, наблюдая за тем, как программируют другие вы сами постоянно учитесь.
  2. Знания о системе: Постоянная смена пар способствует распространению знаний о разных частях системы внутри команды. Это дает возможность понимать как система развивается, улучшать дизайн системы, не дублировать логику.
  3. Коллективное владение кодом: Когда все участвуют в написании всех частей системы, то не может идти речи о персональном владении классом или сборкой.
  4. Наставничество: Все мы когда-то начинали программировать. Как показала практика самое простое вливание в проект происходит в процессе парного программирования.
  5. Больше общения: Общение внутри команды помогает выстраивать доверительные отношения. Стендапы и ретроспективы добавляют в общения в повседневную работу, но это не сравнить с возможностями парного программирования.
  6. Стандарты кодирования: Сидя в паре, постоянно передавая клавиатуру и меняя пары, программисты распространяют знания о том, какие стандарты кодирования приняты на проекте. Вам уже не понадобится прикручивать автоматические инструменты для проверки качества кода.
  7. Улучшение дисциплины: Сидя в паре, хочется показать свою заинтересованность и уровень подготовки партнеру. И довольно трудно временно переключиться на соц. сети, чтобы полистать последние забавные картинки.
  8. Сопряжение потока: Один программист спрашивает у другого «Что мы сейчас решаем?» и они оба начинают погружаться в задачу. Такой подход может приводить к сопряжению состояния потока, что увеличивает продуктивность в разы.
  9. Меньше прерываний: В паре вам приходится меньше прерываться на сторонние факторы, т.к. время двух человек ценнее, чем одного, их работа становится в 2 раза дороже.


Анти-паттерны


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

По моим наблюдениями люди программируют в паре правильно очень редко. Большая часть попыток парного программирования губится одним из перечисленных ниже анти-паттернов.
  1. Наблюдай за Мастером: Это происходит, когда в паре есть программист, который считает (или даже является) гуру в своей области. Вопросы менее опытного разработчика о коде, который генерируется Мастером, не получают ответа. Возможен вариант, когда его постоянно посылают почитать в Google. Мастер не спешит отдавать клавиатуру напарнику, а когда тот добирается до нее, Мастер теряет всякий интерес к процессу.
  2. Диктатор: Один из разработчиков в паре всегда занимает жесткую ультимативную позицию по поводу всех решений, которые касаются текущих задач. В такой ситуации не может идти речи о взаимной помощи или обучении в паре.
  3. Сходи за кофе: Пара садится за компьютер. Один из разработчиков берет клавиатуру и начинает писать код. Говорит напарнику: «Пока я пишу код, ты сходи и налей нам кофе». Это нарушает базовую идею о взаимной вовлеченности программистов в процесс.
  4. Молчаливые партнеры: Напарники не общаются друг с другом и не комментируют свои действия и решения по ходу работы. При отсутствии обратной связи смысл пары теряется.
  5. Разделение задач за одним столом: Программисты садятся в пару, берут два компьютера за одним столом (настольный и ноутбук) и начинают параллельно работать.
  6. Неудобно сидеть: Самая частая причина усталости при работе в паре — неудобное положение клавиатуры и монитора для того, кто сейчас «водитель». Когда клавиатура переходит от одного программиста к другому, получивший ее не перемещается в центр стола, а нагибается к клавиатуре, тем самым создавая себе трудности при работе.
  7. Партнер занят своим делом: Один из партнеров во время работы в паре отдаляется от места работы, проверяет свою почту и т.д.
  8. Свои настройки окружения: Каждый раз, когда управление переходит от одного партнера к другому, начинается перенастройка окружения: закладок, шрифта и т.д.
  9. Свой стиль: Каждый из партнеров придерживается своих стандартов кодирования, что вызывается бурные дискуссии и ужасно отформатированный код.


Как исправить?

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

Границы применимости


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

Дело еще в том, что встречаются задачи, которые нет смысла делать в паре:
  1. Исследовательские задачи: Когда нужно сделать исследование, хорошенько погуглить и пообщаться со специалистами на тему текущей проблемы.
  2. Рутина: Когда абсолютно очевидны следующие шаги, то работа в паре может стать слишком скучной.
  3. Нужно распараллелиться: Если есть две абсолютно разные задачи и сроки поджимаются, то логично не сидеть в паре, а заниматься каждый своей задачей.


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

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



Ссылки

ExtremeProgramming.org: Pair Programming

Pair Programming vs. Code Reviews

Pair Programming Benefits

Код ревью спасет вашу душу

All I Really Need to Know about Pair Programming I Learned In Kindergarten

Pair Programming Benefits: Two Heads Are Better than One

Pair Programming: The disadvantages of 100% pairing