lktalks: Про парное программирование

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

Поводом для данного поста послужило наверное первое серьёзное исследование посвящённое производительности парного программирования.

Но начнём сначала.

Кратко про парное программирование

Для полноты картины кратенько расскажу про парное программирование. Парное программирование - это одна из практик экстремального программирования, которая состоит в том, что код одновременно пишется двумя программистами, сидящими за одним компьютером. При этом в каждый конкретный момент набивает код один из программистов и он как бы отвечает за "тактику". А другой в это время смотрит на этот код, замечает различные ошибки, если они есть и обдумывает этот код на более высоком, так сказать "стратегическом" уровне. Экстремальное программирование конечно заходит совсем далеко и требует чтобы ВЕСЬ код обязательно писался парами. Ну оно потому и называется экстремальным :-) Утверждается, что использование парного программирования способствует достижению массы положительных факторов, таких как:

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

Что об этом думают люди

На самом деле парное программирование конечно придумал вовсе не Кент Бек (отец "экстремального" программирования). Кент Бек популяризировал идею, которая существовала задолго до него. Ну не говоря про то, что люди частенько советовались и даже писали код совместно с коллегами, не придумывая для этого никаких мудрёных названий, Ларри Константин писал про это ещё в 1995 году и тоже не был первым, поскольку говорят откуда-то списал идею :-).

Но с 2000-го года (когда была опубликована книга Бека:Extreme Programming Explained: Embrace Change) многие стали говорить о парном программировании. Высказывались как положительные отзывы и мысли (подобные приведённым выше), так и отрицательные. К основным недостаткам парного программирования обычно относят:

Трудность согласования расписаний программистов - всем нужно быть на работе одновременно, отсюда невозможность работы из дома и по "свободному графику"
Традиционно программисты считаются необщительными людьми, которым просто не захочется писать код вдвоём с кем-то
Традиционно программисты считаются "одиночками", многие из которых очень высоко оценивают собственную работу и очень низко работу всех остальных, что может приводить к конфликтам при работе в паре
Опытный программист может просто не захотеть учить неопытного новичка
Зарплату надо платить обоим, а выигрыш в производительности оценить чрезвычайно сложно, если вообще возможно

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

Эксперименты

Люди начали ставить эксперименты над людях :-) Некоторое время назад в журнале International Journal of Human Computer Studies была опубликована статья Pair programming productivity: Novice–novice vs. expert–expert. Статья рассказывает о четырёх различных исследованиях, проведённых с 1998 года, в которых учёные пытались сравнить производительность парного и соло программирования.

Исследования были такие.

В первом исследовании, проведенном в 1998 году 15 опытных программистов, из которых сформировали 5 пар, и пять соло программистов должны были написать некоторый UNIX скрипт. Результаты оценивались двумя независимыми проверяющими. Оценивались функциональность скрипта (насколько он решал поставленную задачу) и "читаемость" кода. Оценка за качество выставлялась по шкале от 0 до 6 (0 - скрипт не работает, 6 - делает все что нужно). Оценка за "читаемость" выставлялась по шкале от 0 до 2 (0 - невозможно читать, 2 - отличная читаемость). Результаты таковы:

соло

пары

читаемость

1.40

2.00

функциональность

4.20

5.60
В другом исследовании, которое было проведено в 2000 году, участвовал 41 человек,
из которых было сформировано 14 пар и 13 соло программистов. Участвующие были студентами и пары были сформированы так, чтобы в парах обязательно оказывалиь разные по уровню студенты. Задача была в том чтобы написать некое e-commerce приложение. Задачи были несложные и студентам было выдано по 4 задачи. Оценка качества выполнения проводилась при помощи набора тестов. С выполнением первой задачи пары справились на 40 процентов быстрее чем соло. К третьей задаче задачи пары справилялись на 85 процентов быстрее. С точки зрения качества - у пар проходило примерно 90% тестов, а у соло 74%. Надо также сказать, что данный эксперимент проходил без надлежащего контроля со стороны экпериментаторов - участники работали дома и невозможно точно сказать действительно ли работа велась согласно условиям эксперимента.
В 2001 году было проведено третье исследование, в процессе которого студенты, в количестве 21 человек, были разделены на три группы. Каждая группа получила одно и тоже задание и должна была решить его либо при помощи соло программирования либо при помощи парного программирования. Задача состояла в том чтобы подсчитать некоторые стандартные статистические формулы в массиве числовых данных (среднее, медиану), а также подсчитать количество строк кода в заданной программе. Пары и соло потратили практически одно и тоже время на решение задач и поэтому исследователи заключили, что предыдущие оценки продуктивности парного программирования сильно преувеличены.

Все описанные три исследования были проведены разными авторами, и как мы заметили достигли разных и не очень достоверных результатов. Кроме того результаты очень трудно сравнить друг с другом из-за слишком разнеых условий экспериментов и критериев качества результирующих программ. Это же заметили и авторы статьи Pair programming productivity: Novice–novice vs. expert–expert. Они подготовили и провели свой собственный, четвёртый эксперимент. Эксперимент заключался в том, что люди должны были писать одну и ту же программу несколько раз подряд, имитируя таким образом рост профессионального мастерства. Программисты писали одну и ту же программу, каждый раз сначала, 4 раза подряд. Вот график результатов:

	1 итер.	2 итер.	3 итер.	4 итер.
Соло (потраченное время, мин.)	635	407	334	285
Пары (потраченное время, мин.)	410	320	281	272

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

Выводы, которые сделали авторы звучат так:

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

Вот такие были эксперименты. Все они, однако, не идут ни в какое сравнение с экспериментом, который произвели недавно сотрудники Simula Research Laboratory.
В февральском номере журнала IEEE Transactions on Software Engineering опубликована статья Erik Arisholm, Hans Gallis, Tore Dyba и Dag I.K. Sjøberg посвящённая этому исследованию.

О ней, выводах, и моем собственном мнении по всем изложенным и ещё не изложенным поводам - в следующий раз.