Парное, или совместное, программирование является процессом создания программного обеспечения двумя программистами, работающими бок о бок за одним компьютером. С помощью опросов и специальных экспериментов авторы этой статьи исследовали положительные и отрицательные стороны такого стиля работы. Они обнаружили, что при парном программировании время разработки увеличивается на 15%, но при этом улучшается дизайн системы, уменьшается количество дефектов, снижается риск, связанный с занятостью в проекте определенных сотрудников, растет технический уровень команды, улучшается взаимодействие и коммуникация, а кроме того, сам процесс работы в целом доставляет гораздо больше удовольствия.
Humans and Technology 7691 Dell Rd Salt Lake City, UT 84121, USA
arc@acm.org 801.947.9277
Лори Вильямс University of Utah Computer Science 50 S. Central Campus #3190 Salt Lake City, UT 84112, USA
lwilliam@cs.utah.edu 435.649.7931
Original text at: http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm
"Только в том случае, когда различные элементы - имена, определения, намеки и ощущения - тщательно проверяются и подгоняются друг к другу, причем доброжелательно, без неприязни во время обсуждения, только тогда воссияют понимание и здравомыслие - наивысшая цель, которую может поставить перед собой человек…" - Платон
"Как правило, знание создается общими усилиями, благодаря слаженным действиям группы людей, направленным на достижение общей цели, или же благодаря тем проблемам и диалогам, которые порождаются различием их точек зрения." - Габриэль Саломон
Введение
При парном программировании разработчики решают все задачи совместными усилиями, работая бок о бок за одним компьютером. За последние несколько десятков лет такая практика уже неоднократно получала самые лестные отзывы, так как с ее помощью удавалось значительно улучшить процесс разработки ПО.
Однако существует мнение, сводящее на нет любые доводы в пользу парного программирования - многие полагают, что посадить двух программистов за один компьютер, значит поручить двум разработчикам работу одного.
С точки зрения руководителя, программист - слишком ценный ресурс, поэтому он не желает тратить его понапрасну, удваивая количество людей, необходимых для разработки той или иной задачи.
Программисты привыкли считать свою работу индивидуальным, а не коллективным трудом (это убеждение основано как на навыках, которые они получали в процессе обучения, так и на опыте работы).
Многие опытные программисты отказываются работать в паре. Некоторые мотивируют это тем, что их код "слишком индивидуален", другие утверждают, что напарник будет тормозить их работу, третьи говорят, что в таком случае будет очень трудно координировать рабочее время или версии кода.
И в то же время:
Довольно много известных и уважаемых программистов предпочитают парное программирование любому другому стилю работы.
Те программисты, которые уже привыкли к "парному" стилю работы, говорят, что так работается "как минимум, вдвое быстрее".
Что касается качества программы, то опыт показывает, что при парном программировании система имеет лучший дизайн и более простой код, который в будущем можно легко расширять и модифицировать.
Согласно опросам, даже новички-программисты, работающие в паре с опытным специалистом, вносят в его код много полезных дополнений.
Все это поднимает несколько довольно провокационных вопросов. Действительно ли парное программирование эффективнее одиночного? Что оно представляет собой в экономическом плане? И, наконец, нравится ли людям работать в паре? Не теряют ли они удовольствие от работы?
Основываясь на растущем интересе к парному программированию, авторы данной статьи провели несколько опросов и экспериментов, чтобы собрать материал, по которому можно было бы судить об издержках и выгодах, которые несет с собой эта практика. В этой статье мы приводим результаты этого исследования. В прежних публикациях уже говорилось, что парное программирование положительно сказывается на процессе разработки ПО. Цель нашей статьи - перепроверить результаты прежних исследований в этой области и более подробно объяснить, чем же выгодно парное программирование.
Пример использования парного программирования в одном из проектов
Ниже мы приводим цитату из рассказа опытного программиста о том, как его компания впервые попробовала использовать парное программирование. В этом примере упомянуто много основных черт парного программирования, которые мы рассмотрим в этой статье более подробно.
В начале декабря моя команда занялась довольно рискованной деятельностью. Эта деятельность включала в себя внесение изменений практически в каждый файл и слияние фрагментов кода. При всем при этом надо было ничего не сломать. Дальше больше - в архитектуру одной из подсистем потребовалось внести довольно существенные изменения. Итак, с одной стороны, эта работа представляла собой скучнейшую рутину, а с другой - требовала постоянного внимания и напряженной работы мысли.
Разработчики согласились со мной в том, что парное программирование:
– Должно существенно уменьшить риск появления скрытых ошибок, а значит сделать отладку программы менее мучительным процессом;
– Даст нам возможность провести гораздо более полную проверку кода, чем мы когда-либо делали; а кроме того
– Предоставит программистам возможность обмениваться знаниями.
Первые несколько недель работа шла совсем не так, как мы того ожидали. Вместо парного программирования люди начали работать в режиме, который я называю "партнерским программированием". Каждый сам писал свой код, а потом проверял его вместе со своим партнером перед внесением изменений в общий репозиторий. По их словам, благодаря этому они стали находить ошибки на ранних стадиях работы. Звучало обнадеживающе, но я все равно был разочарован тем, что они не работают все время вместе.