Парное программирование. Быть или не быть?

[gleb_l]

Практиковал т.наз. «полупарное» программирование (ППП) — не путать с аббревиатурой медицинского характера ;) — в котором два инженера — лид и ко-пилот например — сидят рядом и пилят каждый свой кусок; при линейных задачах линейно же пилят каждый свое. Если начинается буксование/неопределенность/сложность итд — один обращается к другому с просьбой посмотреть код/обсудить (иногда достаточно просто пересказать проблему соседу) — обычно это имеет эффект. Сложный момент преодолевается. процесс идет дальше.

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

[dipsy]

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

[Vbaranenko]

Как можно писать что-то и вообще думать, если тебе в монитор кто-то смотрит и сопит над ухом. Чисто физически.

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

[dipsy]

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

[BugM]

И ни одна статья не говорит зачем сидеть и смотреть как другой человек жмет на кнопки? А зачем смотреть как другой человек второй час дебажит новый код пытаясь поймать точно сущесвующий, но неуловимый баг?
Что в этом процессе такого увлекательного или полезного?

Чем хуже асинхронный просмотр куска свежего кода называемый код ревью?

[Vbaranenko]

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

[BugM]

Не знаю как вас, а меня помощь коллег при поиске неуловимых багов.

А чем коллеги смогут помочь? Они так же будут тупить в код. Не понимая что я делаю и какую безумную идею проверяю именно сейчас.
А периодически вообще что-то даже говорить даже могут. Будут отвлекать и мешать сосредоточится.

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

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

Зачем коллегам смотреть на этот процесс? В моем говнокоде я сам ничего не пойму уже завтра. Там часть вообще может в районе watches считаться и руками подставляться куда надо. Неповторяемо в принципе. Другой человек тем более не поймет.

А вот чистовой код уже понятен. Там и комментарии могут быть в неочевидных местах. Если что просто подойти и пообщаться можно. Я всегда с радостью словами расскажу что где и почему так. И покажу пальцем.
Потом и комментарий допишу. Раз ревьюеру непонятно было, значит и другим потом непонятно будет. Или вообще перепишу непонятный участок, если у ревьюера будет идея как тоже самое более понятно сделать.

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

[eliduvid]

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

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