Отдел новостей 24 августа 2012, 15:38

Парное программирование: две головы лучше?

Парное программирование – вид так называемого экстремального программирования, которое относится к методологии гибкой разработки Agile. У этого метода есть как плюсы, так и минусы.

Плюсы:

как правило, в этом случае не требуется проводить code review;
даже самый опытный разработчик не может знать всего. Наличие двух программистов помогает быстрее и эффективнее решать задачи;
уменьшается количество ошибок. Кроме того, они чаще всего могут быть обнаружены именно в процессе работы;
разработчики лучше концентрируются и меньше отвлекаются на посторонние дела. Этот пункт можно также отнести и к минусам: постоянные перерывы все же необходимы, поэтому в случае парного программирования рекомендуется делать паузы в 10-20 минут каждые 40-60 минут;
разработчики знают бОльшую часть кода, чем если бы они писали только свою часть. В этом случае они смогут более эффективно вносить изменения в случае надобности;
если нужно сделать слияние двух фрагментов кода, ПП быстрее и эффективнее, чем если бы один разработчик сначала писал код, а потом отправлял его на отправку коллеге, попутно давая объяснения;
разработчики учатся коллективно решать проблемы, обсуждать вопросы, находить компромисс.

Минусы:

не все хотят работать в паре. Кому-то психологически удобнее работать одному, кто-то может быть недоволен партнером. Кроме того, код каждого разработчика индивидуален в той или иной степени;
многие руководители могут посчитать, что это невыгодно – сажать за одно рабочее место двух человек для выполнения одной задачи. Стоимость разработки может возрасти, однако это коменсируется еще одним плюсом – улучшением внутренней архитектуры и меньшим количеством ошибок. В 1999 году было даже проведено исследование на тему временных затрат. Согласно эксперименту, затраченное время выросло на 15%, но при этом ошибок в коде было на 15% меньше. Однако не стоит забывать, что исправление ошибок еще на стадии разработки экономит большое количество времени на поддержке;
необходимо согласовывать график разработчиков;
человеческий фактор. Для ПП необходимо иметь терпение и желание работать в паре. Если один из участников будет просто сидеть молча и смотреть, как второй пишет код, или если один из программистов станет продавливать свое мнение, не прислушиваясь к коллеге, то такой вариант разработки не принесет ни удовольствия, ни эффективности.

Виды ПП

Существует несколько стилей парного программирования:

ведущий-ведомый. В этом случае на втором месте после разработки часто стоит обучение менее опытного программиста, как правило, именно он непосредственно пишет код. Второй программист более опытный, он подсказывает, направляет, дает рекомендации;
на равных. В этом случае работают два примерно одинаковых по опыту разработчиков, время от времени меняющихся местами;
водитель-штурман. В этом случае программисты выбирают разные роли. Один пишет код, разбирается в деталях, а второй занимается архитектурой кода, решением логических задач, рисует схемы;
пинг-понг. Один программист пишет тест, а второй – реализацию под него. После происходит смена ролей;
удаленное ПП. Единственным минусом такого стиля является то, что нельзя тыкнуть пальцем в экран. А если серьезно, то в этом случае можно использовать разные инструменты: например, давать партнеру возможность одновременно с вами писать код или же только видеть ваш экран. Но многое также зависит от от интернет-канала: в случае неполадок на линии работать не получится. Здесь и здесь есть некоторые интересные решения для удаленного ПП. Для такого стиля работы рекомендуют сократить итерации по времени и почаще коммитить код.

Метод ПП можно использовать не только в написании кода. Для отрисовки дизайна он, скорее всего, не подойдет, но вот здесь можно посмотреть на пример ПП в UI-проектировании. В сети также есть упоминания о тройном программировании, однако этот метод вряд ли может претендовать на эффективность разработки.

Область применения

Кент Бек, «отец» экстремального программирования, писал о ПП в своей книге Extreme Programming Explained: Embrace Change. В ней он не дает четких советов о том, для каких проектов подойдет или не подойдет данный метод, но считает, что помехой в ПП могут быть различия в бизнес-культуре участников разработки. По его словам, ПП – не для внеурочной работы, не для разработки в режиме аврала, когда участники уже устали. Кроме того, ПП вряд ли подойдет для проекта, над которым работает сотня разработчиков, а также для рабочей среды, в которой для обратной связи требуется длительный период времени. Кент скептически относится к удаленному ПП. Процитируем еще одно исключение: «Вы не можете использовать экстремальное программирование в случае, если имеете дело с технологией, которая подразумевает экспоненциальный рост затрат, связанных с внесением в систему изменений. Например, если вы имеете дело с мэйнфреймом, планируете использовать установленную на нем реляционную базу данных и не уверены в том, что схема реляционной базы данных в точности соответствует тому, что вам нужно. В подобной ситуации вы не должны использовать ЭП. ЭП основывается на чистом и простом коде. Если вы усложняете код для того, чтобы избежать модификации 200 существующих приложений, в самом скором времени вы потеряете гибкость, ради которой вы, собственно, и решили использовать ЭП».

Что же думают о ПП программисты?

Александр Фомин, lead разработчик C# из Taucraft, делится впечатлениями: – Для каких задач вы использовали ПП? При знакомстве с проектом практически всегда первое задание делалось в паре – вникнуть в суть, понять, «как здесь принято», познакомиться с cross-edge functionality. В начале разработки новой фичи, когда общего решения еще не придумано. В паре архитектура вырисовывается гораздо проще. В сложных местах. Был реальный случай, когда одну штуку я не смог сделать за неделю, а в паре написали за полдня. Правда, возможно, здесь сыграло свою роль то, что над этой штукой я таки неделю думал. Редко, но бывало, когда человек внедряется к уже наполовину сделанной фиче. Правда, сессия получалась недолгой, но это лучший способ вникнуть в процесс. – Как долго использовали ПП? – Зависит от таска, конечно. Одно время – примерно три дня в неделю примерно три месяца, когда делали REST API, – большой кусок полностью с нуля. Сейчас реже, не более трех дней подряд где-то раз в месяц. – Какие у вас остались впечатления от использования данной практики? – Это достаточно сильно изматывает. Из 8 часов в паре удается поработать часов пять-шесть, дальше становится сложно. Но, вместе с этим, время, отработанное в паре, летит незаметно, и к концу дня частенько кажется, что прошла только половина. Многое зависит от второго человека и от стиля работы в паре. Образно говоря, «ведущий-ведомый» лично мне нравится больше, чем «на равных», но это, скорее, черта моего характера. Часто бывает, что сделанное в паре кто-то один потом правит самостоятельно – сильно раздражает, когда это не ты, и очень нравится, когда делаешь сам. Еще важным фактором является скорость работы – иногда бывает, что просто не успеваешь за соседом, тогда приходится терять много времни, чтобы «въехать» или объяснить этот момент.

Выводы

Как видим, ПП не зря относится к экстремальному программированию. Почему-то большинство статей не записывает в минусы повышенную интенсивность разработки и как следствие накопление усталости. С другой стороны, родственники британских ученых считают, что человек способен продуктивно работать 4-5 часов в день, остальное уходит на коммуникацию, околорабочие вопросы и посторонние дела. И в этом случае ПП как раз может быть интересным вариантом использования продуктивного рабочего времени. Исследование Simula Research Laboratory учитывало и психологические аспекты ПП. В нем участвовало почти 300 разработчиков Java. Авторы исследования сделали выводы: ПП показывает наибольшую эффективность при работе в новых областях и при обучении джуниоров. А вот в журнале International Journal of Human Computer Studies были опубликованы результаты другого эксперимента на тему ПП, и выводы оказались также интересными: эффективность пары разработчиков снижается, если один или два участника уже имели опыт решения похожих задач. Получается, что программистов мобилизуют нерешенные вопросы? В целом ПП достаточно популярно в мире разработки. Однако все же большое число разработчиков считают его неприемлемым для работы, а ПП с девушкой приравнивают к семейным отношениям. Разработчики bitbucket показали, что ПП можно использовать не только сидя... Пробовали ли вы парное программирование? Считаете ли приемлемым этот метод для себя или для своей компании?