SPBDEV Blog – Преимущества и недостатки парного программирования

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

Александр Фомин

, lead разработчик C# из Taucraft, делится впечатлениями:

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

# 1: парное программирование может усложнять простые задачи

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

Именно здесь парное программирование встречает наибольшее сопротивление. Простые задачи могут быть усложнены парным программированием.

Хотя это действительно может зависеть от пары. Иногда наличие партнера по паре может повысить моральный дух при работе над простой задачей.

# 2: парное программирование делает процесс адаптации потрясающим

Поскольку передача знаний очень проста в методе парного программирования, адаптация становится легкой.

Новым сотрудникам не нужно проходить «тренировочные лагеря» продолжительностью в неделю или следовать устаревшему руководству по настройке среды.

Новичкам просто назначают партнера по парному программированию и они начинают учиться!

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

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

Эти двое могут уравновесить друг друга.

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

В любом случае, новые сотрудники бесполезны в течение первого месяца работы. Они высасывают ценность из компании, пока не узнают контекст кодовой базы. Согласно методу парного программирования, новички имеют возможность начать приносить прибыль компании в первый день.

# 2: парное программирование не полностью устраняет роль всезнайки

Многие авторы парного программирования преувеличивают, что делает парное программирование для Всезнаек. Некоторые полагают, что парное программирование – это «серебряная пуля» для их исключения. Конечно, спаривание очень помогает в этом вопросе, но в бизнесе трудно утверждать, что что-либо является настоящей «серебряной пулей».

В командах всегда будут люди, которые накапливают важные знания. Это не зло, люди, естественно, тяготеют к этой цели.

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

Тем не менее, можно утверждать, что объединение Всезнаек с другими партнерами по команде – лучшее решение, чем «злодейство и стрельба по лучшим показателям», что является еще одним популярным решением этой проблемы.

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

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

# 3 парное программирование держит сотрудников в чрезмерно напряженном состоянии

В Menlo многие сотрудники говорят, что покидают работу, чувствуя себя «умственно отсталыми»

Они утверждают, что в Menlo думают усерднее и дольше, чем на любой другой работе, которую они когда-либо имели.

Это потому, что невозможно расслабиться, когда у вас есть партнер по парному программированию. Наличие товарища по команде, который наблюдает за тобой весь день, держит тебя супер подотчетным. Трудно срезать углы. Трудно «отключиться» на работе.

Это и хорошо и плохо.

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

Вот почему в Menlo они следят за тем, чтобы пары программистов делали перерывы в течение дня. Утром сотрудники Menlo проводят мероприятие под названием «stand-up», где они делятся тем, над чем они будут работать в этот день. Во второй половине дня они проводят мероприятие под названием «walkies», где они гуляют по кварталу.

Эти умственные перерывы и действия имеют первостепенное значение для успешной культуры парного программирования.

# 3 парные программисты создают кода больше, чем в два раза по сравнению с отдельными лицами, а парная работа отлично подходит для интровертов

Давайте будем честными: большая часть времени, которое программисты проводят на работе, на самом деле уходит не на написание нового кода. Это отладка, разработка стратегий, тестирование и т. д.

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

К счастью, суть программирования сводится не к этому.

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

Отладка – экспоненциальная трата времени. Если кто-то в команде знает решение для ошибки, отладка может занять несколько секунд. Если никто в команде не знает об ошибке, ее отладка займет от нескольких минут до нескольких часов или дней.

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

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

Они также не будут стесняться просить о помощи. Когда какой-то программист застрял в какой-либо проблеме, не очевидно, что он или она сразу обратится за помощью. В конце концов, они могут решить ее через один Google-поиск. Однако, если пара программистов застряла в проблеме, то совершенно очевидно, что они должны обратиться за помощью.

Парное программирование отлично подходит для интровертов. 80% программистов в Menlo идентифицируют себя как интроверты. Тем не менее, они любят метод парного программирования. Зачем? Интроверты любят людей, которые находятся на одной волне с ними.

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

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

Тем не менее, парное программирование не идеально.

Extreme programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%)

его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

1. Разработка через тестирование (Test-driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Onsite customer)
4. Парное программирование (Pair programming)
5. Непрерывная интеграция (Continuous integration)
6. Рефакторинг (Design improvement)
7. Частые небольшие релизы (Small releases)
8. Простота проектирования (Simple design)
9. Метафора системы
10. Коллективное владение кодом (Collective code ownership)
11. Стандарт оформления кода (Coding standard)
12. 40-часовая рабочая неделя (Sustainable pace)

XP сильно напоминает Scrum и предполагает, что заказчик плотно

с командой разработчиков, расставляя приоритеты (истории). Программисты также оценивают, планируют и реализуют задачи короткими итерациями.

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

При этом, если в случае Scrum компания может послать менеджеров проектов на двухдневные курсы, то в случае с экстремальным программированием приходится тренировать всю команду разработчиков. Что гораздо более затратно. Нужно менять культуру в организации, объединяя несколько отделов: XP требует, чтобы тестировщики, UI-дизайнеры, программисты, архитекторы и пользователи работали сообща.

/ Flickr / U.S. Army / CC

Scrum

Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих

синонимом Agile. По статистике за 2022 год,

VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого

инструмент Agile Development.

Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).

Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.

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

На основании списка требований заказчика команда определяет функции, которые хочет реализовать, и начинает свой спринт. Обычно он длится 30 дней. В конце подсчитывается общее количество очков, набранных командой за спринт (скорость). Это позволяет более четко планировать следующие спринты.

За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.

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

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

Однако здесь скрывается проблема: поскольку работа разработчиков оценивается в баллах, они будут стараться заработать их побольше и оптимизировать под это свою деятельность. Что не приводит к улучшению кодовой базы, не делает её проще.

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

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

Без структуры

Наверное, мы перешли к самому забавному стилю. Ведь отсутствие стиля — тоже стиль. Вполне нормально, что в начале работы, когда специалисты находятся на стадии знакомства, прощупывают так называемые «фичи» друг друга. Нужно время для некоторых проб и собственных ошибок, чтобы выбрать подходящий стиль для обоих. Так что, даем волю импровизации.

Варианты спаривания

Эксперт – эксперт

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

Эксперт – новичок

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

Новичок – новичок

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

Ведущий и штурман

Классический стиль работы двух программистов. Ведущий — тот, кто у «штурвала», т.е. за клавиатурой. Решает мелкие задачи. Штурман — наблюдатель, даёт указания и следит за работой, при этом решает глобальные задачи и делает записи.

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

Виды пп

Существует несколько

стилей

парного программирования:

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

Метод ПП можно использовать не только в написании кода. Для отрисовки дизайна он, скорее всего, не подойдет, но вот

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

Водитель-штурман

Что касается уже сложившихся стилей,
давайте сначала рассмотрим пару
«водитель-штурман». Это, пожалуй, самый
устоявшийся стиль.

Название является отсылкой к ситуации,
когда два путешественника едут на машине
по неизвестной им территории. Водитель
сидит за рулем и фокусируется на
тактических вещах, имеющих отношение
к «механике» езды. Он жмет на газ и
тормоз, крутит руль, следит за препятствиями
на дороге и другими машинами.

Перенесите эту метафору в программирование.
«Водитель» осуществляет набор кода,
перемещение между файлами, базовую
реализацию. А «штурман» следит за более
общими идеями и ошибками. Подходит ли
этот метод к выбранной архитектуре? Не
дублируем ли мы уже существующую где-то
реализацию? Не зашли ли мы в тупик?

Подход «водитель-штурман» хорошо
работает в паре двух экспертов, которые
могут меняться ролями. Также он подходит
для пары эксперта и новичка. В последнем
случае лучше, чтобы эксперт был штурманом,
потому что штурман-новичок может сидеть
пассивно, в то время как эксперт будет
играть обе роли сразу.

Индикаторы неисполнения

Есть признаки того, что пара не работает хорошо:

• Отключение может проявляться в том, что один из участников физически отходит от клавиатуры, обращается к электронной почте или даже засыпает.
• «Смотрите Мастер» явление может возникнуть , если один член более опытный , чем другие. В этой ситуации младший член может взять на себя роль наблюдателя, уступая старшему члену пары большую часть действий по кодированию. Это легко может привести к разъединению.

Как уровень навыков влияет
на выбор стиля парного программирования

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

Имея в виду эти два уровня знаний,
подумайте над такими возможными
комбинациями пар:

• эксперт-эксперт,
• эксперт-новичок,
• новичок-новичок.

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

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

Канбан

Scrum по-прежнему остается эффективной методологией, которая пользуется популярностью. Особенно в комбинации с экстремальным программированием. Вместе их процент использования среди Agile-команд

68%.

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

Канбан — это техника для управления разработкой, где процесс разработки рассматривается как конвейер с запросами на реализацию функций, с которого сходит улучшенное программное обеспечение.

Канбан зародился как часть системы производства Тойоты «точно вовремя», поэтому методология исключает излишнее накопление задач. Например, если тестировщики проверяют пять функций за неделю, а разработчики и аналитики реализуют десять, то «общая пропускная способность конвейера» ограничивается до пяти функций.

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

И канбан легко выявляет такие узкие места. В своей простейшей реализации — это большая доска с расчерченными столбцами, в которых размещаются стикеры-карточки. Столбики — это этапы процесса разработки, а стикеры — рабочие задачи. Цифры вверху каждого столбика показывают, сколько карточек разрешено в нем «копить».

Однако, как отмечают в сообществе HN, у такого подхода тоже есть определённые недостатки. В том же Scrum короткие спринты положительно сказываются на мотивации разработчиков. Программисты знают, что работа над продуктом закончится, когда весь список требований на 30 дней будет выполнен.

Также ввиду своей специфики, канбан плохо подходит для долгосрочного планирования и неудобен в работе для крупных команд разработки (больше пяти человек).

Напоследок отметим, что использование Agile-методологий накладывает серьезные требования на опыт членов команды и их способность эффективно взаимодействовать друг с другом. При этом каждая более или менее распространенная методология имеет свои сильные и слабые стороны, а также области применения. По этой причине появляются новые фреймворки и дорабатываются «старые».

P.S. Еще несколько статей из нашего корпоративного блога:

Качество дизайна

Система с двумя программистами обладает большим потенциалом для генерации более разнообразных решений проблем по трем причинам:

1. программисты привносят в задачу различный предыдущий опыт;
2. они могут по-разному оценивать информацию, имеющую отношение к задаче;
3. они по-разному относятся к проблеме в силу своих функциональных ролей.

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

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

Кент Бек

, «отец» экстремального программирования, писал о ПП в своей книге

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

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

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

Обучение

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

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

Парное программирование без
всякой структуры

Представьте парное программирование,
происходящее впервые. Элис заходит в
кабинку к Бобу и говорит: «Ну, давай
поработаем вместе над этим FORTRAN».

Ладно, эта маленькая история может
быть и неправдой, но представьте, как
это может быть на самом деле. Элис и Боб
привыкли к программированию как к
самостоятельной работе, и вот однажды
решили поработать вместе. Они не
обязательно знают какие-либо методы
совместной работы, применимые для
программистов, поэтому просто
импровизируют, стараясь помогать друг
другу.

Это первая парадигма сотрудничества
из тех, что будут перечислены в этой
статье. Знание определенных техник,
которые можно пробовать применять,
безусловно, помогает, но не стоит на них
зацикливаться. Если вы хотите начать,
метод проб и ошибок тоже может быть
очень полезен. Именно таким образом и
складывались все описанные ниже подходы.

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

Пинг–понг

Стиль берет начало из экстремального программирования. Один пишет код, в то время как другой проходит TDD (Test-Driven Development). И также меняются.

Метод работает «на ура» в том случае, если задействованы два эксперта или же два джуниора. В других вариациях возможны помехи, но попробовать, конечно, тоже стоит.

Плюсы:

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

Программирование удаленной пары

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

Удаленное сопряжение создает трудности, отсутствующие при непосредственном сопряжении, такие как дополнительные задержки для координации, в большей степени зависящие от «тяжелых» инструментов отслеживания задач, а не «легких», таких как учетные карточки, и потеря вербального общения, приводящая к путанице и конфликты из-за таких вещей, как «у кого есть клавиатура».

Инструментальная поддержка может быть предоставлена:

Распределенное парное
программирование (на двух компьютерах)

В заключение рассмотрим несколько
«неофициальный» стиль парного
программирования. В нашем мире, где
команды становятся все более глобальными
и распределенными, именно этот стиль
может стать ключевым. Я говорю о
«распределенном» парном программировании.

Но с тех пор пролетело 20 лет, и в связи
с развитием технологий необходимость
физического присутствия существенно
уменьшилась. Используя что-то вроде
Screen Hero, вы можете
довольно плавно работать совместно.
Естественно, просто работа вдвоем за
одним компьютером по-прежнему более
эффективна, но технологии быстро
закрывают эту брешь.

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

Тимбилдинг и общение

Парное программирование позволяет членам команды быстро обмениваться информацией, что снижает вероятность того, что программы будут скрыты друг от друга. Это помогает парным программистам легче научиться общаться. «Это увеличивает пропускную способность и частоту связи внутри проекта, увеличивая общий информационный поток внутри команды».

Удовлетворение

В онлайн-опросе парных программистов в 2000 году 96% программистов заявили, что им больше нравится работать при парном программировании, чем при программировании в одиночку. Более того, 95% сказали, что они были более уверены в своей работе, когда программировали в паре.

Штурман на заднем сиденье

Следующий стиль парного программирования
– штурман, сидящий сзади (в оригинале
– backseat navigator. Так называют пассажира,
который дает непрошеные советы водителю.
– Прим. перев.). Это похоже на работу
в стиле «водитель-штурман», но в данном
случае «штурман», помимо стратегии,
вмешивается еще и в тактику, что и
вызывает ассоциации с непрошеными
советами пассажиров машины.

Как и в паре «водитель-штурман»,
клавиатура находится у «водителя», он
вводит код. Но инструкции по тактике
ему дает его партнер. То есть, он говорит
«водителю», когда создавать метод или
открывать новый файл. Также «штурман»
может указывать, как называть тесты или
переменные.

Этот стиль лучше всего подходит парам
«новичок-эксперт», где новичок играет
роль водителя. Это дает ему возможность
учиться, выполняя все так, как это делал
бы эксперт.

Экономика

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

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

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

Экскурсовод

Еще один стиль, лучше всего подходящий
парам эксперт-новичок, это «экскурсовод».
И снова нам поможет сравнение с вождением.

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

Так это и происходит в парном
программировании в стиле «экскурсовод».
«Водитель» отвечает за стратегию и
тактику, он же и печатает код. Параллельно
он поясняет свои действия «туристу».
Сам «турист» при этом редко вмешивается
в процесс.

Это хорошо работает в паре, где
«водитель» – эксперт, а «турист» –
новичок, в частности, абсолютный новичок.
Но и при обратном раскладе это тоже
работает. Вы садите новичка за клавиатуру
и предоставляете ему самостоятельно
сражаться с проблемой (некоторое время),
а эксперт наблюдает. Затем эксперт дает
фидбэк, исправляет ошибки, и процесс
повторяется.

Выводы

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

учитывало и психологические аспекты ПП. В нем участвовало почти 300 разработчиков Java. Авторы исследования сделали выводы:

ПП показывает наибольшую эффективность при работе в новых областях и при обучении джуниоров

. А вот в журнале International Journal of Human Computer Studies были опубликованы результаты другого эксперимента на тему ПП, и выводы оказались также интересными:

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

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

к семейным отношениям. Разработчики bitbucket

, что ПП можно использовать не только сидя…

Пробовали ли вы парное программирование? Считаете ли приемлемым этот метод для себя или для своей компании?