Старая поговорка: «Две головы лучше, чем одна».

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

Я часто слышу, как люди говорят, что они могут показать все, что в их силах, когда они работают в одиночку. Кроме того, я понимаю, что некоторые идеи / методы, полезные для одного человека, могут не подходить для другого. Однако я твердо верю в фразу о том, что «две головы лучше, чем одна». Два видео ниже - отличные музыкальные примеры того, как два человека работают «гармонично» и с большим успехом. Первая - «Соната для фортепиано в четыре руки ре мажор, K.381 / 123a» Моцарта, а вторая - пьеса для гитары в четыре руки «Tico Tico no Fubá» Зекиньи де Абреу:

Музыка, безусловно, не единственная сфера, где сотрудничество может быть полезным для успеха проекта. Майкл П. Фаррелл, профессор социологии в Университете Буффало, провел исследование тесных творческих групп в своей книге Коллаборативные круги: динамика дружбы и творческая работа. В исследовании рассматривалась групповая динамика в шести совместных кругах, таких как социальные реформаторы Элизабет Кэди Стэнтон и Сьюзен Б. Энтони, а также К. С. Льюис, Дж. Р. Р. Толкин и Инклинги. Он писал: Большинство хрупких озарений, которые легли в основу нового видения, проявились не тогда, когда вся группа была вместе и не когда члены работали поодиночке, а когда они сотрудничали и отвечали друг другу парами.

В истории много раз, когда сотрудничество давало основу для значительных результатов; Моне и Ренуар, Пабло Пикассо и Жорж Брак, Бэтмен и Робин… список можно продолжить! Фактически, за последние тридцать пять лет около половины Нобелевских премий по физиологии и медицине было получено научным партнерством.

В статье «Полномочия двух: поиск сущности инноваций в творческих парах» Джошуа Вольф Шенк цитирует интервью, в котором Джон Леннон объяснил, что либо он, либо Пол Маккартни «напишут хорошее, та часть, которая была простой, например, «Я прочитал сегодня новости» или что-то еще ». Одному из них не хватало вдохновения, пока не появился другой. Леннон продолжил: «Я бы спел половину, а он был бы вдохновлен написать следующий бит, и наоборот». Любой может время от времени впадать в творческую колею, но это редкость для два человека должны делать это одновременно.

Формальное определение парного программирования в Википедии гласит:

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

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

В структуре парного программирования есть две роли: водитель и навигатор.

Драйвер - это тот, кто держит руки на клавиатуре и пишет код.
навигатор - это тот, кто наблюдает и просматривает каждую строку кода по мере ее ввода.

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

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

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

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

Сопряжение и поток рабочих станций

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

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

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

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

Некоторые преимущества:

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

Несколько советов, которые следует запомнить:

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

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

Вышеупомянутая цитата мне очень понравилась. Кроме того, мое первоначальное вдохновение для этого сообщения в блоге пришло из чтения статьи The New Yorker Дружба, которая сделала Google. (Проверьте это! Это отличное чтение). В статье подробно рассказывается, как Джефф Дин и Санджай Гемават стали старшими научными сотрудниками Google - первыми и единственными инженерами 11 уровня в компании. Если два ведущих инженера Google смогли успешно изменить путь развития компании и Интернета в целом, это наводит меня на мысль, что существует значительная корреляция между парным программированием и достижением больших высот.

В заключение…

Ллевеллин Фалько, успешный коуч по гибкому программированию, использует фразу парное программирование в строгом стиле. Он говорит: Чтобы идея перешла из вашей головы в компьютер, она должна пройти через чьи-то руки. Этот стиль программирования направлен на улучшение общения и сотрудничества . Мой главный вывод из сообщения в блоге Ллевеллина заключается в том, что общение и сотрудничество - основа успеха.

Лично я могу сказать по опыту, что я гораздо более продуктивен в паре или группе. Мой музыкальный опыт научил меня тому, что я предпочитаю выступать в ансамбле, чем быть сольным артистом. Дело не в том, что я полагаюсь на другого человека (людей), скорее, моя уверенность возрастает в геометрической прогрессии, когда я чувствую себя в некоторой степени обязанным действовать лучше, чем в одиночку. Кроме того, я из тех людей, которые питаются энергией других людей. Когда я использую парную программу, моя производительность значительно увеличивается. Мои текущие навыки показали мне, что я в настоящее время лучше навигатор, чем водитель, но я планирую сосредоточиться на том и другом. Я надеюсь, что, прочитав это, вы поймете, почему такой тип сотрудничества поощряется и может быть полезен для ваших будущих проектов.