О парном программировании говорят не так часто. Если кратко, то это методика, когда над одним участком кода, проектом работают два разработчика. Обычно один из них пишет код, второй комментирует и помогает. Такая методика не панацея, но она многое даёт как компании, в которой отлажены такие процессы, так и самим специалистам. Об этом говорим под катом.
Почему стоит использовать парное программирование?
В первую очередь потому, что оно значительно экономит время на рефакторинг. Когда над одним участком работают два программиста, в коде становится меньше багов. Соответственно, сокращается время на отладку, поскольку уходит сразу несколько итераций вроде оформления багов в багтрекинге, взаимодействия с тестерами, исправления, повторного тестирования.
Вот основные преимущества методики:
Повышается скорость работы. Разработчики гораздо меньше отвлекаются на побочные задачи, общение с коллегами (кроме напарника) и разного рода кофе-брейки и перекуры. Прокрастинации при таком способе нет.
Увеличивается скорость отладки. Два человека могут гораздо быстрее найти проблему в коде, чем один. У одного глаз может быть «замылен», а второй быстро обнаружит баг.
Растёт качество кода. Если программист, который кодит, допускает ошибки или качество кода падает, то второй это замечает и помогает исправить ситуацию.
Передача опыта и обучение. Парное программирование позволяет оперативно обмениваться знаниями и опытом, лучше использовать инструментарий и др.
Согласно данным ряда исследований, с одним из которых можно ознакомиться вот по этой ссылке, парное программирование позволяет снизить количество багов примерно на 10-20% плюс сократить объём самого кода. Кроме того, опрошенные в ходе исследования разработчики заявили, что они более уверены в результате, чем в случае одиночной работы. Такой ответ дали 95% опрошенных программистов.
Как всё это реализуется на практике
Команда проекта не начинает работу просто так — сел и поехал. Сначала задача обсуждается, намечается план (лучше на бумаге или в электронном виде), а потом уже все приступают к работе. Что касается пары разработчиков, то они каждые полчаса или час меняются ролями. Один пишет код, его роль принято называть «штурманом», второй этот код чекает, мониторит и составляет стратегию работы, его роль — «ведущий».
Рабочий процесс выглядит следующим образом:
у разработчиков должна быть чёткая задача
её нужно разбить на небольшие цели, которые фиксируются
пара должна меняться ролями, смена активности всегда помогает в работе
каждый должен заниматься задачей в рамках своей роли: если разработчик пишет код, то «стратегически» должен мыслить «штурман», а «ведущий» — работать с тактикой и деталями
Такой способ эффективен и в случае работы двух специалистов с примерно равным опытом, и в случае пары «новичок — опытный сотрудник». Речь идёт об опыте работы в самой компании, понятно, что пара «джун — мидл» хорошие результаты вряд ли покажет. Второй случай хорош для обучения и онбординга. Но именно знания и опыт работы с определённым стеком должны быть примерно равными.
Если серьёзный проект ляжет на плечи пары «джун — мидл», то джун будет чувствовать себя, образно говоря, машиной для ввода символов, а второй быстро начнёт нервничать, поскольку неопытный разработчик может не знать многое из того, что нужно для работы.
Кстати, пара «джун — джун» тоже возможна. И она даже необходима, если задача не самая сложная. Дело в том, что в процессе работы оба программиста неплохо прокачают навыки и знания. Речь здесь как о хард-, так и софт-скилах.
Кроме того, рекомендуется раз в пару недель или месяц пары менять, поскольку сотрудники могут просто уставать друг от друга. За пару недель разработчики рассказывают друг другу почти всё, что знают сами, поэтому для получения новых знаний лучше давать сотрудникам возможность общаться с новыми членами команды.
Очень важно позаботиться и о состоянии рабочего места. В частности, жизненно необходимо:
планировать время совместной работы: кодить и отдыхать нужно в одно и то же время, за рабочим местом оба программиста должны присутствовать одновременно
учитывать опыт и предпочтения: у пары должен быть опыт работы с выбранным IDE и стеком технологий, в противном случае один будет путаться в новой для себя среде, а второй — получать стресс в чистом виде
убедиться в совместимости участников: сотрудники должны быть в хороших отношениях друг с другом, ведь если у них есть проблемы с личным общением, хорошей работы не получится
подготовить рабочее место: оба программиста должны чувствовать себя комфортно за рабочим столом — должно быть несколько мониторов, две клавиатуры и производительный компьютер
Что делать, если в компании не практикуется парное программирование?
Если разработчику хочется попробовать такой метод, но в компании его не практикуют, можно попробовать участвовать в чемпионатах и соревнованиях. В этом случае проблемы нет. Разработчики, которые принимают участие в таких мероприятиях, получают огромное количество опыта и дополнительные знания, плюс здорово прокачивается социальный скил.
Комментарии (43)
quakin
29.08.2023 17:31+5Пробовал парное программирование со своими сотрудниками в далёком 2005 году, когда мода на Agile только зарождалась. Несмотря на энтузиазм, никто не нашёл очевидных причин продолжать. Да, есть плюс - повышается качество кода (меньше багов, лучше читаемость и поддерживаемость). Но -- с моей точки зрения -- та же задача хорошо решается меньшими силами с помощью классического код-ревью.
Skykharkov
29.08.2023 17:31+10Парное программирование, это как секс втроем. Разочек конечно попробовать можно, но постоянно... Я пробовал (я про програмирование, конечно), уже через пару часов хочется набить напарнику лицо, чтобы не отвлекал, гадина такая...
zloddey
29.08.2023 17:31Я вот люблю ПП, но пара часов - это реально много. Обычно стараюсь заранее ограничивать сеанс парной работы одним часом, не более. В таком режиме обычно получается и реальный результат получить, и не сгореть при этом дотла.
Skykharkov
29.08.2023 17:31Да и круг задач весьма узок, как по мне, для применения ПП. Наверное, это хорошо, если делать дизайн например. Или проектировать (не програмировать) базу или там API какое-то). Но в режиме глубокого кодинга, когда "вошел в инсайт" и пишешь в нем, отвлекает любая мелочь. Кроме кошки на коленях. Вот ей можно всё.
zloddey
29.08.2023 17:31круг задач весьма узок
Круг задач вообще не принципиален. Любую задачу, которую делает один человек, можно делать вдвоём или командой. Обратное верно не всегда :)
Состояние потока в ПП тоже вполне успешно ловится, если оба человека достаточно чётко соблюдают роли. В чём особенность потока? В том, что обозримый кусок задачи "помещается в рабочую память" целиком, как что-то единое. Нет необходимости что-то периодически загружать из долговременной памяти и сбивать контекст. И в ПП, если люди чётко соблюдают роли, это достигается ещё проще, потому что задача делится между двумя людьми. Водитель пишет код, не отвлекаясь на глобальную картину, а фокусируясь на правильности кодинга (флоу данных, структуры, имена переменных, и т.д.). Навигатор, наоборот, фокусируется на маршруте до цели: какой шаг делаем сейчас, какой будет следующим, какие у нас будут препятствия и т.д.
Задача вроде бы и та же, но в голову каждого участника надо загружать уже меньший кусок. Поэтому и потока достигнуть в целом проще, и выходить не так болезненно.
Tzimie
29.08.2023 17:31+11Я интроверт. Идите на...
sshikov
29.08.2023 17:31Я думаю, если были бы убедительные доказательства, что эта методика эффективна, и дает хотя бы процентов 20 прироста производительности, или повышает качество, ваш начальник уговорил бы вас побыть немного экстравертом ;) За деньги, скажем.
Tzimie
29.08.2023 17:31+3Нет. Это один из немногих случаев когда деньги бы ничего не решили. Я вообще не терплю когда у меня стоят за плечами, а тут это все время.
aleks-th
29.08.2023 17:31+1Да не, вы просто путаете когда стоят за плечом. И когда рядом мотивированный напарник.
Тут можно быть сто раз интровертом и не испытывать никаких сложностей.
Не знаю как в программировании, но хотел бы узнать на практике, а в других делах мне очень нравится совместная работа, все получается быстрее и точнее, хоть я тоже интроверт, но никогда не испытывал сложностей в работе с напарником.
Tzimie
29.08.2023 17:31+3Значит вы экстраверт, возможно in denial
SatoVandal
29.08.2023 17:31+1Пожалуйста, прекратите путать интроверсию с социофобией и прочими
бедами с башкойособенностями психики конкретных людей, а из экстравертов делать болтунов-весельчаков.
Общение может утомлять и тех, и других, и все будет зависеть от контекста. Не стоит упрощать людей до значения 1 или 0, когда это огромная и многомерная шкала.
sshikov
29.08.2023 17:31Может для вас и не решили бы, а кто-то бы согласился. Но опять же — если бы эффект был доказан, это стало бы выглядеть так, что вы "не желаете работать на 20 процентов эффективнее, прикрываясь справкой, что вы интроверт". Или наоборот, в доказательстве эффективности было бы написано что-то типа "интровертов в это не вовлекать, на них нифига не работает". Но никто ведь не умеет так мерять...
zloddey
29.08.2023 17:31Начальники (по моему опыту) чаще любят мыслить в терминах "ресурсного менеджмента". Типа, люди все кубически-одинаковые, не меняются, не учатся, обладают одинаковым набором знаний и умений. Поэтому лучший способ работы - это накидать им максимум задач для работы в параллель. С таким подходом у ПП тупо нет шансов, потому что это ведь "два юнита работают над одной задачей, а могли бы работать над двумя!".
sshikov
29.08.2023 17:31По-моему, методы управления людьми очень редко дают гарантированный прирост производительности даже в 10%. А так чтобы постоянно, а не на время — наверное вообще никогда. Я уже не говорю о том, что производительность умственного труда (включая программирование) вообще мерять очень сложно, потому что все задачи разные.
"два юнита работают над одной задачей, а могли бы работать над двумя!".
Ну так а я вам про что? Выглядит это ровно так, как вы описали, что производительность у пары 100% вместо 200%, а циферок, которые бы показали, что эти двое работают хотя бы на 220% — их нет (или они есть, но для какого-то другого проекта, в котором в первую очередь другие люди, а во-вторую — другие задачи). Поэтому доказать начальнику, что парное программирование эффективно — очень сложно.
aleks-th
29.08.2023 17:31+1Про парное программирование много читал, и на самом деле я бы попробовал так поработать. Просто пока такой работы не попадалось, но если бы была возможность то попробовал бы так поработать.
По идее должно вырасти качество работы и уравнятся компетенции с напарником, что в свою очередь было бы очень полезно.
odilovoybek
29.08.2023 17:31+1Для этого нужно чтобы напарник был другом или знал меньше вас и не указывал на ошибки, а просто предлагал идеи и дальнейшие действия.
Другие сценарии очень стрессовые.
aleks-th
29.08.2023 17:31+2Да наоборот.
У меня самое лучшее развитие было , когда мы с напарником бизнес открыли. Он был компетентен в одних вещах, я в других, и мы постоянно на ошибки друг другу тыркали. Никакой дружбы только работа.
Как итог очень хорошее развитие, обменялись компетенциями и каждый чему-то очень хорошо научился у другого.
Здесь будет так же обмен опытом , причем хороший такой обмен.
olku
29.08.2023 17:31+2Гугл говорил, что парное программирование заменяет ревью. Но не все могут позволить себе двоих на работу одного.
zloddey
29.08.2023 17:31не все могут позволить себе двоих на работу одного
Выглядит как весомый аргумент. Но случалось ли Вам попадать в ситуацию, когда PR делается за условные два дня, а потом неделю обсуждается и переделывается на ревью? Или ситуация, когда один человек делает работу самостоятельно и по невнимательности (или из-за незнания каких-то нюансов) привозит кучу дефектов, которые потом за ним двое-трое коллег вынуждены подчищать в дополнение к собственным задачам?
Парное программирование выглядит как переработка, но разве описанные примеры не являются точно такой же переработкой? Там, где два человека могли сесть и за час совместной работы разрулить большую часть спорных моментов, мы берём и устраиваем распределённую болтологию на несколько дней, когда каждый из участников должен заново восстанавливать контекст беседы.
ПП не серебрянная пуля и нужно не всегда. Но его надо уметь применять в тех случаях, когда альтернативы приводят к худшему результату. А умение работать в паре приходит через практику. Т.е., через "сесть и попробовать".
olku
29.08.2023 17:31Случалось. Но от распределённой болталогии мало помогало, ибо программирование все таки парное, а накидать на вентилятор без критериев приемки и наличия свободного времени может кто угодно. Мнение напарника в этом случае ничего не значит. Особенно, если в тред прилетает какой-нибудь вип. Конечно, это пример больной организации.
JuryPol
29.08.2023 17:31+1Первая проблема в том, что выгоды, те, что можно измерить, исчисляются в лучшем случае парой десятков процентов. А один разработчик в минусе.
Вторая проблема - трудно подобрать пару. Слишком многое должно совпасть. У меня есть двое знакомых ребят, которые в таком режиме работают пару десятков лет. Но не постоянно, а время от времени.
Сам я пробовал. Могу сказать только, что постоянно работать в таком режиме я бы не хотел.
И еще… обучение и выравнивание компетенций в таком режиме - это фикция. Желаемое за действительное…
zloddey
29.08.2023 17:31обучение и выравнивание компетенций в таком режиме - это фикция
Позвольте поинтересоваться, как именно происходило разделение работы в этих случаях?
В теории, возможно два основных варианта: либо работу делает более опытный товарищ, либо менее опытный. Первый вариант действительно плох для обучения. Чтобы получить новые навыки, человеку обычно необходимо "пропустить" их через свои руки. Т.е., кодить должен менее опытный человек, а более опытный должен направлять его действия через "высокоуровневые" инструкции. Это даёт новичку возможность освоить что-то новое для себя и закрепить это на практике.
Другой вопрос в том, что не каждый опытный коллега бывает готов принять роль учителя в таком сетапе. Руки так и чешутся перехватить управление и сделать всё самому. "Это же так просто, смотри: раз, два, три". Задача вроде бы и сделана, но закрепления навыка у менее опытного коллеги не происходит. Это обязанность более опытного человека - контролировать свой позыв сделать всё за коллегу.
JuryPol
29.08.2023 17:31+1Вот видите, сколько условий возникает. Более опытный дает "высокоуровневые" инструкции, а у ведомого - вот сюрприз, никакого отклика. Ему нужно дать спокойно разложить в своей голове свое представление о теме, услышанный посыл, выстроить взаимосвязи, создать свою собственную картинку, в его собственных представлениях и привычных терминах. Честное слово, лучше первый акт такого освоения проводить в режиме простого обучения, без маячащего у плеча ментора. А уж для закрепления - пожалуйте играться в парное программирование. Может и повезет, сойдутся звезды и понятливый ученик при флегматичном и понятливом учителе освоит новый прием.
Упомянутые мной выше ребята привыкли еще с института работать в паре, лабы, курсовики и т.д. Поэтому у них пошло.
А самая опасность подобной инициативы в том, что на нее первыми среагируют профессиональные никчемушники, которые быстренько обставят эту инициативу кипиаями, графиками замен разработчиков, дашбордами и красивыми картинками из квадратиков и треугольничков с кружочками. Быстренько посчитают нужные проценты, доложат где надо, получат бонусы и уйдут трепать нервы другим и по другому поводу.
Все слышали про "Работает - не трогай", но почему-то некоторые считают, что разработчиков нужно постоянно шевелить и дергать. Если инициатива возникает в команде разработчиков - пусть пробуют, им расплевываться. Если это эйчары, методологи и прочие мастера по всему, что не приколочено, то пусть они идут в сад...
zloddey
29.08.2023 17:31Относительно "профессиональных никчемушников" соглашусь. Это метода, которая нужна (или не нужна) в первую очередь самим разработчикам, а не прихлебателям вокруг. Команда должна сама решать, какие методы использовать, а какие нет.
ReadOnlySadUser
29.08.2023 17:31Попробовал с год назад парное программирование, как способ ускорить интеграцию миддла в проект.
Первый месяц он самостоятельно разбирался с базовыми вещами, а потом я попробовал с ним совместно поработать несколько дней. В итоге, одни нервы с двух сторон. Код ревью эпизодический лайвкодинг, для отображения дел, тупо проще и быстрее)
zloddey
29.08.2023 17:31+1Может, больше пользы было бы, если бы Вы применяли ПП именно в первый месяц? Это как раз тот этап, когда у новичка постоянно возникают вопросы, и наличие рядом человека, который может на них сразу же ответить, ускоряет процесс адаптации в разы. Какие-то вещи могут лежать в документации, а какие-то нет. Команда привыкла "делать вот так" и считает какие-то вещи самоочевидными. А у новичка этого видения ещё нет. Как только он начинает делать что-то по-своему, естественным образом возникает повод для дискуссии. Или когда стопорится, потому что не знает, где и как получить нужную для следующего шага информацию.
Если же он месяц обживался в проекте в одиночку и вырабатывал своё собственное видение проекта и правил работы на нём, то не надо удивляться, что оно разойдётся с видением остальных членов команды. Не в этом ли кроется причина "нервов с двух сторон"?
ReadOnlySadUser
29.08.2023 17:31Парное программирование, подразумевает собой процесс, в котором код поочередно пишут оба. В первый месяц человек вообще ничего в проекте не знает и не понимает.
Понятное дело, что в первый месяц я и отдельную вводную проводил, и на все вопросы отвечал, но парным программированием это не назвать.
panzerfaust
29.08.2023 17:31+6МТС, а вы просто так для бложика откопали эту стюардессу? Или у вас реально такие практики в компании и вы реально видите буст каких-то показателей?
Мне каждый раз смешно видеть блоги от бигтеха с такими вот мудростями. Потом приходишь в этот самый бигтех - а там не то что парного погромирования нет, там даже нормальный нейминг переменных и функций не освоили и тестов 3.5 штуки на 1кк строк кода.
AndreyDmitriev
29.08.2023 17:31+6У меня есть опыт парного программирования, хотя и несколько специфический (извините за мегакоммент).
Было это году этак в 2003, третий год в Германии, и занесла меня нелёгкая вместе с коллегой на один автомобильный завод в баварской глубинке. Пусконаладка промышленного рентгеновского оборудования для неразрушающего контроля блоков цилиндров. Жаркое лето, литейный цех, конвейер, всё шумит и грохочет, температура в цеху под сорок, кондиционер в кабине радиационной защиты едва справляется, мозги кипят, всё как мы любим. И вот значит пошёл я к автомату купить холодной газировки и с удивлением обнаружил, что рядом с бутылками лимонада там в автомате стоит холодное пиво! Как сейчас помню - лимонад по 50 евроцентов, а пиво Францисканер - по 70, что ли. Я вернулся к коллеге и спросил его "— то есть если я куплю пиво и вот так вот посреди рабочего дня выпью и мне за это ничего не будет?!". Он мне: "— понимаешь, в Баварии пиво, это как бы не совсем алкогольный напиток, это продукт питания - Grundnahrungsmittel, ну вот как хлеб, но разве что жидкий". За обедом я обнаружил в заводской столовой разливное, ну и взял кружечку. На следующий день я решил употребить бутылочку перед обедом для поднятия аппетита, так сказать, ну а через пару дней бутылка пива заменила привычную утреннюю чашечку кофе.
Все мы знаем, что максимальную продуктивность программист достигает в состоянии "потока", когда окружающий мир словно перестаёт существовать, вот только достичь этого состояния бывает непросто, чтобы выйти из прокрастинации и "войти в поток". К началу второй недели я уверенно входил в это состояние "нирваны" уже к обеду. Коллега, видя такое дело, взял стул и пересел рядом со мной, внимательно наблюдая за моими действиями и поправляя меня, когда я мазал по клавишам, а я выдавал мегатонны
говнокода, прерываясь лишь на то, чтобы взять новую бутылочку из холодильника. Полёт мысли было не остановить — хитрое индексирование, кэширование, обход графов — всё давалось легко и непринуждённо. К концу третьей недели командировки всё было почти готово, там по ходу мы решили оптимизировать перемещение робота-манипулятора (для просвечивания блока цилиндров требуется около восьмидесяти позиций), и фактически я был уже готов решить задачу коммивояжера для восьмидесяти городов. " — Знаешь, Райнер, тут есть мааленькая, ик, проблемка... Количесво возможных траекторий, ик, оно слегонца превышает количество атомов во Вселенной... - "вот здесь, в этом месте тебе нужно остановиться", — сказал коллега, поглядывая на батарею пустых бутылок. К слову, нам удалось сделать неплохое приближение — мы ускорили систему процентов этак на двадцать. Код этот двадцатилетней давности, довольно быстро перешедший в состояние "тут ничего не трогать, а то сломаешь" вспоминаю до сих пор с ностальгией, хотя там не всё так уж плохо, даже местами аккуратно - коллега попутно рефакторил его и обкладывал тестами, когда я отлучался.Если серьёзно, то опыт был в общем позитивный - коллега рядом работал в роли живого статического анализатора и указывал на ошибки (в основном когда я что-то копипастил, но забывал менять индексы, или переменные), подсказывал какие-то паттерны, которых я "не видел", но одновременно было довольно высокое напряжение, которое мы, впрочем, успешно снимали вечером в баре (нет, мы не алкоголики, но командировка — случай особый). Подходит для узкого круга нестандартных задач, требующих внимательности и коротких мозговых штурмов, но постоянно мы так не работаем, обычно более продуктивно разбить задачу на две и дальше каждый спокойно делает свою часть работы. Ещё важна сработанность — мы понимали друг друга буквально "с полуслова".
Ну а пиво - через несколько лет оно исчезло из заводских автоматов и из меню в столовой. Что поделать, времена меняются.
zubrbonasus
29.08.2023 17:31Если вместо одного разраба, одной задачей занимаются двое, тогда стоимость решения задачи умножается на условную 2 (или прибавляется зп синиора). Если каждый программист займётся своей задачей, а в конце задач будет проведено cross-review, тогда и стоимость задачи останется обыкновенной, и качество кода будет расти (для прокачки джуна кросс-ревью джунами + контрольный от старшего разраба) - 2 зайца из двустволки.
Enextus
29.08.2023 17:31вы наверное в 2000х годах? ChatGPT давно за 20€ в месяц!!! О чём вообще эта статья???
Karopka
29.08.2023 17:31Я как-то участвовал в таком цирке.
На какое-то время производительность заметно выросла, однако в результате оба кодера вымотались, как грузчики после разгрузки состава с углём.
Больше мы так не делаем. Работа программистом должна приносить удовольствие.
Arch213
29.08.2023 17:31+1Работаю джуном в Испании. Минимум 3 раза в неделю проводим парное программирование с сеньорами.Очень сильно вырос за 6 месяцев как разработчик ????????
headliner1985
29.08.2023 17:31Пробовал парное программирование, в нашей команде оно не зашло, тк по итогу всё равно программирует один, а второй из-за перегруза информации просто кодит, и тратиться время двух человек. По итогу зашло программирование тройками, на случай сложных задач. Один человек пишет код и вообще не думает, называется драйвером, а два других рассуждают над задачей и говорят что писать. Да это тройное расходование времени, но зато хоть есть результат. Повторюсь применяли для сложных ситуаций, когда были проблемы и человек приходил за помощью, на постоянной основе нет смысла.
aol-nnov
Встречал оценку с другой стороны: парное программирование - высокий стресс для пишущего код.
Разделяю оба утрерждения, и то, что в статье и то, что привел сам.
Применять парное программирование на постоянной основе считаю напряжной практикой.
zloddey
Стресс стрессом, но зато после определённого объёма подобных тренировок проходить live coding на собеседованиях становится просто плёвым делом!
Я считаю, что ПП следует применять так же, как и остальные практики, - по необходимости. В каких-то случаях больше, в каких-то меньше. Самое сложное - это просто начать. Если команда хотя бы иногда применяет этот подход, то и сам процесс становится менее стрессовым.
aol-nnov
Для меня это звучит примерно так же, как "олимпиадное программирование" - крутое и бесполезное.
Цель нашей жизни - создавать, а не раз в две недели ходить на лайв кодинг...
С этим я полностью согласен. Осознанность действий и осознание необходимости - на первом месте в любом начинании должна быть.
Изначальный мой посыл не в том, что стресс от наличия ПП в практиках команды. Стресс от того, что кто-то постоянно стоит над душой и комментирует, направляет мысль не в ту сторону, "куда хотел автор". У многих подгорает в этот момент. Есть реальные случаи в моей практике, когда мне приходилось корректировать "сюжетную линию" непосредственно в момент её рождения, что чрезвычайно негативно сказывалось на эго авторов изначальной задумки. (Но это уже совсем другая история)
zloddey
Лёгкий и приятный live coding - это, скорее, приятный побочный эффект ПП, а вовсе не цель. Не будем про него сейчас.
Вопрос же корректировки сюжетной линии как раз важен. Весь смысл разделения ролей в ПП ("водитель-навигатор") состоит в том, чтобы один человек владел "сюжетной линией" (навигатор), а второй осуществлял по ней движение (водитель). Если у двух человек возникают разногласия по маршруту (это в целом достаточно часто возникает), надо останавливаться и обсуждать/разрешать разногласия. Может оказаться, что один из вариантов приводит к определённым проблемам, и по нему идти нельзя. А может оказаться, что это прежде всего вопрос вкуса. Во втором случае очень полезно применять подход "попробуем сначала по-твоему, а потом по-моему и сравним оба подхода". Когда перед глазами есть написанный код, у него обычно всё же проще оценить достоинства и недостатки, чем у изначальной сырой идеи.
Но после того, как направление движения согласовано, "водитель" не должен отклоняться от курса, который ему указывает "навигатор". Коль хочется поуправлять самому - предлагай смену ролей и отдавай клавиатуру. Если оба человека следуют протоколу, то это не воспринимается как "кто-то стоит над душой". Просто два человека делают совместно одно дело.
Но повторюсь ещё раз: эти навыки нарабатываются через практику в первую очередь. Поэтому, чтобы их получить, надо практиковаться в ПП хотя бы как-то, а потом анализировать возникающие проблемы, корректировать свои подходы и пробовать снова. Этим ПП не отличается от других типичных практик в разработке типа отладки, тестирования, соло-кодинга и т.п.
aol-nnov
Теоретически - да, всё складно и правильно изложено.
На (моей) практике - выглядит, как розовые единороги, бегающие по радуге (т.е. недостижимым), увы, увы... И всё такое взаимодействие скатывается к формату "против кого дружить будем?" Возможно, я недостаточно повидал за свои 20 с лишним лет стажа, но факт..
zloddey
Я излагаю не теорию, а выжимку из собственного опыта.
"Бутстрап" - это в ПП самое сложное, факт. На пути к практике стоит психологическая преграда в виде "человека за спиной", а без практики не возникает навыков правильного взаимодействия, которые помогают с этой преградой бороться. Поэтому многие так и не осваивают эту технику.
Мне, наверно, повезло на старте. Мы с другом в школе (тоже 20+ лет назад) пытались писать игры на его компьютере. Комп был один, а нас двое - и ПП родилось как-то само собой из этого ограничения. Только спустя несколько лет я узнал об экстремальном программировании и этом вот всём.
Возможно, это прям важный момент: когда мы работали вдвоём над игрой, то фокусировались на задаче, а не на оценивании друг друга. Не было прессинга, которым сегодняшний процесс промышленной разработки просто перенасыщен: джира-таски, дейлики, дедлайны, что сделали за спринт и т.д. Мы просто творили в вольном режиме для собственного удовольствия. А сейчас что? Берёшь задачу, и в голове тут же начинает тикать таймер: "надо уложиться в изначальную оценку!". Отправил код на ревью, а там какой-то чёрт придирается к второстепенным мелочам. Задержка, переработка, противник! Сложно его за такое полюбить и согласиться, чтобы он код начал смотреть сразу.
Когда-то ещё до массовой удалёнки я пробовал проводить в офисе на выходных сеансы Code Retreat с добровольцами. Это как раз хорошая техника для отработки ПП на практике с живыми людьми. За 1 день можно успеть поработать с 5-6 разными людьми (1 сессия длится 45 минут, между ними перерывчик минут в 15). Задача игрушечная, легаси кода нет, поэтому можно сфокусироваться на отработке деталей техники - либо ПП, либо TDD, либо рефакторинга... Заходило тоже не всем, но таких было меньшинство. Остальным, надеюсь, пригодилось.
Ещё один практический подход, который может помочь подойти к ПП, - это работа не вдвоём, а целом командой. Берём кусок кода, шарим его на всех, и вместе пробуем менять. Например, упрощаем какой-то запутанный участок легаси. Конечно, есть риск, что всё свалится в срач - может потребоваться модератор. Но если цель у всех общая и настрой командный, то что-то полезное да получится. Главная задача - уменьшить нервозность от ситуации, когда в код кто-то кроме тебя смотрит. В толпе такой прессинг меньше, чем тет-а-тет. Так можно наиграть чувство локтя, и потом уже пробовать подходы к парной работе (если нужно).
Не воспринимайте этот комментарий как попытку "совратить" лично Вас на ПП. Скорее, я пишу его уже для остальных читателей. Типа, кто-то заинтересуется темой, придёт в статью, потом спустится в комментарии, увидит типичные возражения - а тут вот он, мой ответ с рекомендациями. Если кто-то не не готов пробовать ПП, да и ладно.
aol-nnov
Нет-нет, наоборот - я благодарен за то, что делитесь вашим опытом и все мои ремарки о пони, бегающих по радуге, скорее не саркастические, а с нотками белой зависти в попытках сопоставить мою реальность с вашими рассказами :)
psycho-coder
В моей недолгой практике ПП, еще когда учился, мы разделяли роли на "мышевоз" - тот кто рулит мышкой, писали на Delphi, и кто пишет код.
В процессе каждый спокойно говорил, что и кому делать, причем со временем происходило понимание и много слов для объяснений не требовалось. Замечания по коду или "оформлению" формы принимались спокойно. Код обсуждался, но писал его тот кто за клавиатурой, иногда только, когда не получалось объяснить, что хочет мышевоз - он брал клаву и быстро правил, дальше роль сохраналась.
К такому решению пришли не сразу, но пришли. Продуктивность была довольно хорошая и дейстивтельно можно было узнать друг от друга немного нового, т.к. что-то изучали самостоятельно вне занятий.