Парное программирование: преимущества и недостатки (ЛП)

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

Разработчики согласились со мной в том, что парное программирование:

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

- Даст нам возможность провести гораздо более полную проверку кода, чем мы когда-либо делали; а кроме того

- Предоставит программистам возможность обмениваться знаниями.

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

Приблизительно через четыре месяца я стал замечать некоторые изменения. Одна пара разработчиков весь день работала всместе - это было настоящее парное программирование. Другие две пары тоже были близки к этому идеалу. В процессе обсуждения стало ясно, почему изменения в процессе все-таки произошли. Так было удобнее работать!

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

Наконец, мы подготовили промежуточную версию системы и отдали ее в отдел контроля качества (QA). К нашему удивлению, процесс тестирования прошел без сучка без задоринки. Это было тем более удивительно, что одну из подсистем некоторое время назад целых шесть (!) недель мучили в отделе QA. Было совершенно очевидно, что парное программирование коренным образом уменьшило количество дефектов в системе.

С течением времени сотрудничество программистов становилось все более тесным.

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

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

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

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

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

Направления исследования

Мы рассмотрим здесь восемь направлений исследования, связанных с программированием и организационной эффективностью. Удивительно, но все они свидетельствуют в пользу парного программирования. Итак, мы вели наши исследовали в следующих направлениях:

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

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