Идея парного программирования в том, что работа над любым продуктовым кодом должна вестись совместно: вместе дизайним, пилим, ломаем и чиним. По идее, не должно быть ни одной закоммиченной строки кода, которые не прошли бы через 4 руки. И хотя в некоторых случаях совместная работа может быть полезной и продуктивной, но в подобной формулировке мне она всегда казалась через чур экстремальной.
До последнего времени у меня не было личного опыта парного программирования, поэтому мое мнение было сугубо теоретическим. За последние полгода у меня появился какой-то опыт, и именно им и хотелось бы поделиться.
Итак, начнем с проблем.
Проблема #1. Психологическая и рабочая несовместимость
Главная проблема в этой затее в том, что нельзя (ИМХО) просто взять двух членов команды, приковать их наручником к клавиатуре и получить хороший код на выходе. У разных людей разные мыслительные процессы и разные подходы к работе. Для кого-то нормально набросать кучку другую кода, увидеть результат, потом его причесать. Для другого нужно порисовать на листочке бумаге, написать тест, потом закодить все одним махом. Для третьего важно что-то еще.
Если процессы как с точки зрения головы, так и с точки зрения работы не совпадают, то нормально работать за одной клавиатурой будет очень сложно. Возможно, удастся притереться, но если пара не очень-то подходит друг к другу, то сработаться будет сложно.
Проблема #2. Несоответствие в опыте
Эффективное парное программирование подразумевает равный опыт. Это не работа вида подмастерье-мастер. Здесь должна быть пара пусть и с разным, но с соразмеряемым уровнем. Да и опыт в предметной области и в конкретной технологии должны быть соизмеримы.
Если опыт будет существенно отличаться, то работа в паре превратиться в работу одного человека и стороннего наблюдателя, который быстро потеряется в деталях и сможет давать лишь поверхностные советы. Элемент обучения будет, но эффективность будет невысокой.
Проблема #3. Парная работа не подходит для любых задач
Есть виды деятельности, которые просто не имеет смысла выполнять совместно. Когда нужно допилить десяток граничных условий или причесать код для соответствия стилю программирования, то делать это в 4 руки – это просто waste of time.
Проблема #4. Парная работа утомляет
“Pair programming is tiring but satisfying. Most programmers can’t pair for more than five or six hours in a day.” – Kent Beck
Кен считает, что вполне нормальным проработать в паре 5-6 часов в день. Как по мне, то это практически невозможно. Поработав полтора-два часа уже чувствуешь приличную усталость и я просто не представляю, как в таком режиме можно проработать 6 часов.
Проблема #5. Парная работа требует погружения в контекст
“Rotate pairs frequently. Some teams report good results obeying a timer that tells them to shift partners every sixty minutes (every thirty minutes when solving difficult problems).” – Kent Beck
Любая сложная работа требует времени на погружение в контекст и, опять же, я просто не представляю, как можно тасовать пары каждый час. Каждый день? Возможно. Если пара работает над смежными задачами и совместно решает вопросы интеграции? Без вопросов. Но меняться по принципу каждый с каждым внутри команды каждый час? Звучит очень сомнительно.
Когда парное программирование работает?
Есть ряд областей, в которых парное программирование применяется очень давно. Первые две – это отладка и проектирование.
Отлаживать совместно – это сверх удобно и практически всегда работает. Еще Джон «Я могу отладить все, что угодно» Роббинс в своей «Отладке приложений» рассказывал историю об отладке приложений с фарфоровыми кошечками. Но, понятное дело, пара глаз и толковая голова позади них – это намного лучше. Незашоренный взгляд помогает весьма быстро найти проблему за пару минут, даже если ты сам уже потратил на нее пару часов.
Проектирование – это еще одна область, где хорошо работать в слаженной паре. Тут и брейнсторминг, и рисование кубиков/квадратиков/стрелочек. Все это позволяет сгенерировать больше идей и хорошенько их просеять. Тут важно не переборщить и не привлекать сильно много людей и, как всегда, знать с кем именно дизайнить совместно.
Решение сложных проблем, не связанных с отладкой – это еще одна интересная область. Сесть совместно и набросать полупрототипное решение – это очень хорошо делать в паре. Тут совместный опыт помогает быстрее разобраться в злом окружении и избежать “tunnel vision”, обходя препятствия наиболее прагматичным образом.
Слабать совместный кусок, который связывает куски, над которыми два человека работали изолировано – просто идеальное для парной работы.
Писать же код продакшн качества мне показалось совершенно излишним. С точки зрения продуктивности – это не эффективно, а вопросы с качеством и шарингом знаний легко решаются с помощью рецензирования кода.
З.Ы. А у кого какой опыт парного программирования? Делитесь, плз!
> Эффективное парное программирование подразумевает равный опыт.
ОтветитьУдалитьС этим можно поспорить. Для меня одна из реально полезных фишек парного программирования в том, что в пару можно посадить новичка и опытного программиста как раз с целью более быстрого обучения и погружения новичка в проект. Это работает, но для этого нужно, чтобы за клавиатурой сидел новичок, а опытный программист подсказывал и рассказывал.
Если же опытный программист все пишет сам лишь изредка давая какие-то комментарии -- вот это плохо.
Но чтобы такая схема работала, нужно, чтобы у опытного программиста было желание выступать в качестве наставника. Т.е. приходим к проблеме №1 из твоего списка.
Если я не ошибаюсь, то термин "парное программирование" берёт свои истоки из XP. Так вот автор этой методологии у обязательные условия ставит равенство опыта. То что можно усадить "разноопытных" людей вместе и от этого будет толк - возможно, но это уже будет скорее менторство, введение в проект и т.п., но не парное программирование в понимании автора.
УдалитьЕвгений, я полностью согласен, что работа в паре ради менторства - это хорошее дело, но, как правильно заметил Алексей, эта тактика не покрывает те цели, которые ставил Кент Бек, описывая эту технику.
УдалитьДа, с точки зрения обучения - это будет полезно, но на качество результирующего продукта (а именно в этом заключалась цель) это не повлияет.
Ну и тут модель работы должна быть совсем не такая (что не хорошо и не плохо)...
И да, у опытного товарища должно быть большое желание именно делиться, а не просто делать...
З.Ы. Я менторил довольно много, но это скорее обратный процесс: менее опытный человек пишет, а более опытный - смотрит и "наставляет". Работает, но у меня всегда это было в форме "shoulder code review", а не в форме парной работы.
@Oleksiy Davidich
УдалитьЯ просто сказал про ситуацию, когда от парного программирования есть ощутимый и легко отслеживаемый положительный эффект. То, что это противоречит определению Бека -- ну это, наверное, проблемы Бека. Или мои :)
Если я правильно понимаю автор этой статьи заявляет, что если целью парного программирование является не обучение молодого работника, то в данном случаи это не эффективно
УдалитьМне парное программирование иногда импонирует. Например, я могу не знать (точнее, мне лень узнавать) детали кривой реализации в проекте, но вот другому человеку это может нравиться ввиду того, что он знает как оно там работает. Почему бы и не совместить? Или банально иногда бывают дни, когда целый день чувствуешь себя уставшим, и эта вся затея здорово помогает. Но именно иногда. Одним ещё минусом могу назвать проблемы, создаваемые гибким графиком, когда кто-то приходит или слишком рано, или слишком поздно. Или когда "парный" идёт обедать в компании других людей, графики с которыми вряд ли совпадают.
ОтветитьУдалитьЭто как сковывание цепью. Вообще считаю, что парное программирование есть ни что иное как ограничение личной свободы. Мне, например, не получалось в то время как-то переключиться на наушники просто для того, чтобы расслабиться (хотя у меня был ещё и отдельный рабочий ноут), или, например, переключиться на другие менее важные задачи, когда эта работа мне просто не идёт.
И да, наверное, главным недостатком можно назвать п.1: психологическую несовместимость. Был у нас один разработчик, который не стеснялся просто в офисе (опен-спейс) слово через слово применять ругань и иногда заводился так, что создавал впечатление не совсем уравновешенного. Мне он всегда был неприятен, хотя технически он был вовсе неплох и мы состоим где-то на одном уровне компетенции. Итак, когда тимлид сообщил что эту неделю мы пишем код вместе, у меня мысленно упала челюсть, но, думаю: посмотрим, обменяемся опытом, не умру же и всё такое. В итоге на любые минимальные замечание по поводу его кода он отвечал довольно агрессивно, хотя иногда и принимал во внимание мелкие детали. Ну и мне, как, пожалуй, перфекционисту, такой код резал глаза, сами решения не всегда были оптимальными (хотя, честно говоря, я довольно плохо разбирался в том проекте), но напарник видел в этом красоту. А, и да: я выступал исключительно в роли весьма застенчивого комментатора, что порядком стало скучным вусмерть. И я просто ради того, чтобы не портить отношения с человеком, всё оставшееся время провёл за своим ноутом, пока у коллеги дым из-под пальцев шёл. Т.е., формально мы работали вместе, но никакого парного программирования, обмена опытом и т.д. попросту не было.
Спустя некоторое время мне повезло перевестись на другой проект, где я уже мог заниматься вполне привычной для меня разработкой без каких-либо этих "хипстерских методологий". Некоторое время у меня даже тоска возникала по поводу того, что я пишу сам. Но, имея хорошую команду, можно просто попросить тиммейта уделить немного своего свободного времени, когда сам не уверен как решить ту или иную задачу. И это касается как проектирования, так и уже иногда очень мелких деталей реализации. И кстати да, по поводу отладки: так отлаживать действительно куда удобней, и я просил коллег помочь мне в этом, или присоединялся к ним, если у них возникала такая необходимость. Я надеюсь, что коллеги по команде думают так же.
Отличное дополнение. Спасибо.
УдалитьТоже имею примерно такой же опыт, поэтому считаю,что для продакшна плохо подходит, особенно если еще и опыт разный у программистов. На мой взгляд просто потеря времени.
УдалитьА вот для отладки очень хорошо подходит. Здесь как раз опыт положительный.
Тут не совсем понятно, правильно ли понимается парное программирование. В процессе должно быть два человека - driver & navigator. Driver только набирает код, решает текущую задачу, navigator следит за направлением и думает об архитектуре и куда дальше пойдет код. Он не следит за стилем. И это не постоянные роли, пара постоянно меняет роли. В день человек должен быть не более, чем 70% в одной роли. Оптимально 50/50.
ОтветитьУдалить>> Психологическая и рабочая несовместимость
Не все люди могут быть в паре. Надо не боятся спрашивать вопросы. Надо постоянно говорить и объяснять, зачем это происходит. Надо говорить иногда теперь моя очередь программировать.
Есть неадекваты. В Украине их было очень много, за рубежом значительно меньше. Ответ один не нанимать и увольнять неадекватов.
>> Несоответствие в опыте
Тяжело, но все равно можно. Первый шаг для джуниора - пинг-понг программирование. Маленький тест, а второй человек его чинит. Потом второй пишет тест, а первый чинит. Идет по принципу " делай как я". Потом спрашивать про рефакторинг. Тормозить во время слишком преждевременного рефакторинга и объяснять почему. Второй шаг - давать джуниору писать код. Как можно больше. Заставлять его спрашивать вопросы, учить его искать код в текушем проекте, в параллельных проектах, в старых проектах. Показывать, где можно спросить.
>> Парная работа не подходит для любых задач
Идеальная работа, чтоб показывать, как что устроено в проекте. По поводу стиля - можно написать вместе какую-нибудь программку, которая исправляет код. Или падает во время тестов.
Очень хорошо протись с человеком, который не был на текущей задаче и объяснить, как код работает и обсудить с ним граничные условия.
>> Парная работа утомляет
Перерывы каждые полтора часа. Постоянная смена ролей. Через месяц становится проще
>> Парная работа требует погружения в контекст
Убивает поток и это хорошо. Потому что каждый день надо возвращаться назад и объяснять почему что-то было сделано и зачем. Как в анекдоте про Эйнштейна - объяснять так много раз, что и понять самому. У нас был очень контекстноемкий баг в начале прошлого года. Третий человек, которому я это объяснял, увидел ошибку в воспроизведении этого бага локально. Благодаря этому , мы поняли, что все время работали над неправильным местом. Через два месяца детали этого бага уже знало двадцать человек.
Во многом согласен с плюсами и минусами.
ОтветитьУдалитьНа работе часто выносим на командное обсуждение какие-то новые решения, а так же с удовольствием ковыряем вместе мистические проблемы на продакшене.
Совместный кодинг используется редко.
Но вот совсем недавно всё таки прибегнули именно к кодингу в рамках решения задачи для нового проекта. Новый продукт должен стать придатком к уже существующей экосистеме, о которой у команды очень отдалённое понимание. Над одной из задач один программист пыхтел почти неделю и мало куда продвинулся. А после 4-5 часов совместных усилий с человеком, который в курсе нюансов "экосистемы", задача была закомичена и он с лучшим пониманием происходящего ринулся эфективно решать остальные задачи.
Единственное, что вызывает сомнение в вышесказанном, это фраза:
> Писать же код продакшн качества мне показалось совершенно излишним. С точки зрения продуктивности – это не эффективно, а вопросы с качеством и шарингом знаний легко решаются с помощью рецензирования кода.
Чисто гипотетически, рискну предположить, что эфективность сложно измерить на короткой дистанции. Это как с юнит тестами - сначаала вроде дольше, а в итоге быстрее. В парном программировании нужно учесть время на код-ревью, переделку кода, которую прийдётся сделать из-за того что одному программисту сразу не пришло в голову правильное решения, и т.д.
Бертран Мейер говорил, что в своё время были эксперименты, которые доказали равнозначность "парного программирования" и "одиночного + код ревью" в отношении эфективности.
> Единственное, что вызывает сомнение в вышесказанном, это фраза:
УдалитьДа, вполне возможно, что дело в отсутствии положительного опыта... и мое мнение изменится в случае наличие оного:)
> Бертран Мейер говорил, что в своё время были эксперименты, которые доказали равнозначность "парного программирования" и "одиночного + код ревью" в отношении эфективности.
Да, слышал от него такое же.
Отладка - однозначно. Разбор легаси кода тоже работает.
ОтветитьУдалитьНу и имплементация-отладка какого-нибудь хитрого куска (либо алгоритмически либо структурно) + последующие размышления как это сделать человеко-читаемым.
По моему опыту для отладки никакого парного программирования не нужно.
ОтветитьУдалитьА вот построение архитектуры - самое то. Начинали новый проект и в течении двух недель только и делали что рисовали возле доски и писали интерфейсы. Отличный опыт, который сэкономил кучу времени.