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

Парное программирование – вид так называемого экстремального программирования, которое относится к методологии гибкой разработки 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 показали, что ПП можно использовать не только сидя... Пробовали ли вы парное программирование? Считаете ли приемлемым этот метод для себя или для своей компании?

Место солидарности беларусского ИТ-комьюнити

Далучайся!