При парном программировании разработчики решают все задачи совместными усилиями, работая бок о бок за одним компьютером. За последние несколько десятков лет такая практика уже неоднократно получала самые лестные отзывы, так как с ее помощью удавалось значительно улучшить процесс разработки ПО.
Однако существует мнение, сводящее на нет любые доводы в пользу парного программирования - многие полагают, что посадить двух программистов за один компьютер, значит поручить двум разработчикам работу одного.
С точки зрения руководителя, программист - слишком ценный ресурс, поэтому он не желает тратить его понапрасну, удваивая количество людей, необходимых для разработки той или иной задачи.
Программисты привыкли считать свою работу индивидуальным, а не коллективным трудом (это убеждение основано как на навыках, которые они получали в процессе обучения, так и на опыте работы).
Многие опытные программисты отказываются работать в паре. Некоторые мотивируют это тем, что их код "слишком индивидуален", другие утверждают, что напарник будет тормозить их работу, третьи говорят, что в таком случае будет очень трудно координировать рабочее время или версии кода.
И в то же время:
Довольно много известных и уважаемых программистов предпочитают парное программирование любому другому стилю работы.
Те программисты, которые уже привыкли к "парному" стилю работы, говорят, что так работается "как минимум, вдвое быстрее".
Что касается качества программы, то опыт показывает, что при парном программировании система имеет лучший дизайн и более простой код, который в будущем можно легко расширять и модифицировать.
Согласно опросам, даже новички-программисты, работающие в паре с опытным специалистом, вносят в его код много полезных дополнений.
Все это поднимает несколько довольно провокационных вопросов. Действительно ли парное программирование эффективнее одиночного? Что оно представляет собой в экономическом плане? И, наконец, нравится ли людям работать в паре? Не теряют ли они удовольствие от работы?
Основываясь на растущем интересе к парному программированию, авторы данной статьи провели несколько опросов и экспериментов, чтобы собрать материал, по которому можно было бы судить об издержках и выгодах, которые несет с собой эта практика. В этой статье мы приводим результаты этого исследования. В прежних публикациях уже говорилось, что парное программирование положительно сказывается на процессе разработки ПО. Цель нашей статьи - перепроверить результаты прежних исследований в этой области и более подробно объяснить, чем же выгодно парное программирование.
Пример использования парного программирования в одном из проектов
Ниже мы приводим цитату из рассказа опытного программиста о том, как его компания впервые попробовала использовать парное программирование. В этом примере упомянуто много основных черт парного программирования, которые мы рассмотрим в этой статье более подробно.
В начале декабря моя команда занялась довольно рискованной деятельностью. Эта деятельность включала в себя внесение изменений практически в каждый файл и слияние фрагментов кода. При всем при этом надо было ничего не сломать. Дальше больше - в архитектуру одной из подсистем потребовалось внести довольно существенные изменения. Итак, с одной стороны, эта работа представляла собой скучнейшую рутину, а с другой - требовала постоянного внимания и напряженной работы мысли.
Разработчики согласились со мной в том, что парное программирование:
- Должно существенно уменьшить риск появления скрытых ошибок, а значит сделать отладку программы менее мучительным процессом;
- Даст нам возможность провести гораздо более полную проверку кода, чем мы когда-либо делали; а кроме того
- Предоставит программистам возможность обмениваться знаниями.
Первые несколько недель работа шла совсем не так, как мы того ожидали. Вместо парного программирования люди начали работать в режиме, который я называю "партнерским программированием". Каждый сам писал свой код, а потом проверял его вместе со своим партнером перед внесением изменений в общий репозиторий. По их словам, благодаря этому они стали находить ошибки на ранних стадиях работы. Звучало обнадеживающе, но я все равно был разочарован тем, что они не работают все время вместе.
