Экстремальное программирование: Pair Programming



    Парное программирование является одной из практик XP. Эта практика воплощает экстремальную (преувеличенную) идею Code Review. Если ревью позволяет улучшить качество кода, то давайте делать его постоянно, во время рефакторинга и написания нового кода.

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

    Как это делать?


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

    Исследования


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

    Исследования показывают, что работа в паре делает либо с такой же скоростью, как и по одиночке, либо немного (15%) медленнее. Зато код получается намного качественней, содержит меньше ошибок (60%) и технических долгов.

    Результаты исследований, приведенных ниже, очень схожи с моими наблюдениями в повседневной работе. К тому же я, как преподаватель в ЮУрГУ, начал давать парное программирование с самого начала своего курса. Мои результаты будут в конце учебного года, а пока подборка публичных исследований на тему:


    Бонусы от парного программирования
    1. Обмен опытом: Часто бывает, что сидя в паре вы узнаете про пару новых горячих клавиш, интересные утилиты для ускорения работы. В любом случае, наблюдая за тем, как программируют другие вы сами постоянно учитесь.
    2. Знания о системе: Постоянная смена пар способствует распространению знаний о разных частях системы внутри команды. Это дает возможность понимать как система развивается, улучшать дизайн системы, не дублировать логику.
    3. Коллективное владение кодом: Когда все участвуют в написании всех частей системы, то не может идти речи о персональном владении классом или сборкой.
    4. Наставничество: Все мы когда-то начинали программировать. Как показала практика самое простое вливание в проект происходит в процессе парного программирования.
    5. Больше общения: Общение внутри команды помогает выстраивать доверительные отношения. Стендапы и ретроспективы добавляют в общения в повседневную работу, но это не сравнить с возможностями парного программирования.
    6. Стандарты кодирования: Сидя в паре, постоянно передавая клавиатуру и меняя пары, программисты распространяют знания о том, какие стандарты кодирования приняты на проекте. Вам уже не понадобится прикручивать автоматические инструменты для проверки качества кода.
    7. Улучшение дисциплины: Сидя в паре, хочется показать свою заинтересованность и уровень подготовки партнеру. И довольно трудно временно переключиться на соц. сети, чтобы полистать последние забавные картинки.
    8. Сопряжение потока: Один программист спрашивает у другого «Что мы сейчас решаем?» и они оба начинают погружаться в задачу. Такой подход может приводить к сопряжению состояния потока, что увеличивает продуктивность в разы.
    9. Меньше прерываний: В паре вам приходится меньше прерываться на сторонние факторы, т.к. время двух человек ценнее, чем одного, их работа становится в 2 раза дороже.


    Анти-паттерны


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

    По моим наблюдениями люди программируют в паре правильно очень редко. Большая часть попыток парного программирования губится одним из перечисленных ниже анти-паттернов.
    1. Наблюдай за Мастером: Это происходит, когда в паре есть программист, который считает (или даже является) гуру в своей области. Вопросы менее опытного разработчика о коде, который генерируется Мастером, не получают ответа. Возможен вариант, когда его постоянно посылают почитать в Google. Мастер не спешит отдавать клавиатуру напарнику, а когда тот добирается до нее, Мастер теряет всякий интерес к процессу.
    2. Диктатор: Один из разработчиков в паре всегда занимает жесткую ультимативную позицию по поводу всех решений, которые касаются текущих задач. В такой ситуации не может идти речи о взаимной помощи или обучении в паре.
    3. Сходи за кофе: Пара садится за компьютер. Один из разработчиков берет клавиатуру и начинает писать код. Говорит напарнику: «Пока я пишу код, ты сходи и налей нам кофе». Это нарушает базовую идею о взаимной вовлеченности программистов в процесс.
    4. Молчаливые партнеры: Напарники не общаются друг с другом и не комментируют свои действия и решения по ходу работы. При отсутствии обратной связи смысл пары теряется.
    5. Разделение задач за одним столом: Программисты садятся в пару, берут два компьютера за одним столом (настольный и ноутбук) и начинают параллельно работать.
    6. Неудобно сидеть: Самая частая причина усталости при работе в паре — неудобное положение клавиатуры и монитора для того, кто сейчас «водитель». Когда клавиатура переходит от одного программиста к другому, получивший ее не перемещается в центр стола, а нагибается к клавиатуре, тем самым создавая себе трудности при работе.
    7. Партнер занят своим делом: Один из партнеров во время работы в паре отдаляется от места работы, проверяет свою почту и т.д.
    8. Свои настройки окружения: Каждый раз, когда управление переходит от одного партнера к другому, начинается перенастройка окружения: закладок, шрифта и т.д.
    9. Свой стиль: Каждый из партнеров придерживается своих стандартов кодирования, что вызывается бурные дискуссии и ужасно отформатированный код.


    Как исправить?

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

    Границы применимости


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

    Дело еще в том, что встречаются задачи, которые нет смысла делать в паре:
    1. Исследовательские задачи: Когда нужно сделать исследование, хорошенько погуглить и пообщаться со специалистами на тему текущей проблемы.
    2. Рутина: Когда абсолютно очевидны следующие шаги, то работа в паре может стать слишком скучной.
    3. Нужно распараллелиться: Если есть две абсолютно разные задачи и сроки поджимаются, то логично не сидеть в паре, а заниматься каждый своей задачей.


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

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




    Ссылки

    ExtremeProgramming.org: Pair Programming

    Pair Programming vs. Code Reviews

    Pair Programming Benefits

    Код ревью спасет вашу душу

    All I Really Need to Know about Pair Programming I Learned In Kindergarten

    Pair Programming Benefits: Two Heads Are Better than One

    Pair Programming: The disadvantages of 100% pairing
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 63

      +3
      Да простят меня приверженцы XP и прочих методологий, я просто оставлю это тут…
        +1
        Можно делать ЭТО и в паре. Неужели вы никогда не звали никого на помощь, чтобы рядом с вами поседели, а вы объяснили в чем проблема?
          +25
          Поседели от вашего кода :)
            +1
            Хорошая опечаточка! От некоторого кода и вправду можно поседеть :)
              –1
              Самое обидное, что это не «опечаточка», а самая, что ни на есть ОШИБКА! Да простят студенты преподавателю ЮУрГУ его слабости… в русском языке, и надеюсь, что в «профильном» языке таких багов нет!
            +1
            Делали и не только в паре. Несомненно эффект наблюдателя играет свою роль, но это мало относится к тем правилам, которые были описаны Кентом Беком и другими. Главная проблема же заключается в том, что после увеличения частоты появлений на слуху трендовых словечек (читай agile, scrum, xp, kanban...) начинаются неизбежные попытки доказать (в первую очередь самому себе), что мы тоже доросли и разбираемся в том как правильно организовать процесс разработки. Ты начинаешь внимательно изучать труды основоположников методологий, может быть даже посещать конференции и слушать доклады тренеров, а этих хитрецов сейчас пруд пруди и далее применять это все на практике, попутно навязывая всем кому не лень. В некоторых случаях тебе даже кажется, что это приносит профит и ты горд и удовлетворен. Но погоня продолжается, т.к. ты узнаешь что в другой команде применяется, со слов рассказчиков, более эффективный подход и ты изучаешь дальше… а потом осознаешь, что все это раньше называлось адекватностью и здравым смыслом, а сейчас — эджайлом, который тем самым принес больше вреда, чем пользы и время можно было потратить на изучение материалов, относящимся к практикам разработки или на отдых.
              0
              и да — «эффект наблюдателя» я упоминал применительно к парному программированию, которое не является синонимом xp, как многие ошибочно полагают
            –2
            Вот потом программисты которые толком то и не знакомы с экстремальным программирование, скрамами и CI начинают материть эти подходы.
              +3
              Есть такое. Обычно, все, кто матерят (которых я знаю), даже и не представляют процесса.

              Типичный диалог:
              — Что это за г… нокд? Почему два разных интерфейса слили в один просто собрав методы первого и второго, несмотря на то, что они пересекаются?
              — Это мы объединяли быстро, не было времени. (по ТДД)

              Т.е. юнит-тесты были? нет. Не говоря о том, что писать раньше кода. Рефакторинг был? Нет.

              Зато ТДД в сознаниях — источник г… нокодов.

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

              И на счет манифеста «пишите код, бл… ть». Пишут код все. Но по разному. Я в паре не работал. Скорее всего это дает свой эффект. Но дело не в методологиях управления, а в навыках проектирования и кодирования. В навыках определения, что нужно прямо сейчас, в навыках рефакторинга — определения, в какой вид код должен быть приведен, чтобы соответствовать точно тому, что нужно сейчас. Моделировать предметную область. Понимать, что является реализацией, хитростью, а что является отражением требований. Это навыки именно кодирования. Методологиями управления эти пробелы не закроешь.
              А работа в паре, видимо, способствует всего лишь овладению этими навыками. Т.е. учебе за счет работодателя. И если это делает работу эффективнее, даже параллельно с учебой, то почему нет — хорошая технология.

              Но по-моему, эффективнее было бы, если бы книг побольше с разобранными примерами было, описывающими необходимые навыки.
                0
                Бинго.

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


                Не только навыками, а также обеспечивает быстрое вливание в команду нового человека.
                Я думаю, что это самый логичный случай использования парного программирования.
                При этом новичок пишет код, а наблюдатель корректирует и отвечает на вопросы.
                  0
                  Это самый большой плюс от парного программирования. Все остальное вполне можно заменить техникой и технологией написания кода.
                    +1
                    Это слишком упрощённый взгляд на ПП.
                    На самом деле самый большой плюс от ПП в том, что оно поддерживает высокую сконцентрированность практически весь рабочий день и стимулирует программистов обсуждать (а значит, продумывать) проблему до того, как начинать её делать. Это только теоретически «можно заменить техникой», а на практике — фиг там.
                      +1
                      Продолжительная высокая концентрация приводит к более сильной усталости, что приведет к ухудшению качества кода, снижению мотивации и удовлетворенности от результатов труда. Нужно очень аккуратно следить за количеством стресса от парного программирования, чтобы держать эффективность труда на должном уровне.

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

                        Когда есть задачи и когда они не десятиминутные, то бывает так увлекаешься, что оторваться тяжело на «бытовые» нужды )))

                        Обсуждение — хорошо. Если не отвлекает. Чужой взгляд тоже дает эффект. Потому как много раз замечал: вроде всё понимаю ясно и делаю всё, кажется, верно, но если рядом другой человек и он спросит «почему так», то замечаю свои ошибки. Да и вообще-то, я пишу код не для себя. И если другому человеку не понятно, это сигнал, что код объективно непонятный.

                        Это хорошо, только непонятно, будет ли пара работать эффективнее, чем по одному. Даже если немного качественнее, но два человека тратили время.
                          0
                          > Если выключить все отвлекающие вещи и войти в ритм
                          :) Вот-вот. Если. В том-то и фокус, что это «если» далеко не всегда случается. А с ПП всегда.

                          А в остальном всё так, да.
                          Ну вот, мой опыт показывает, что пара будет работать эффективнее. Код много качественнее, решения много проще.
                            0
                            Да элементарно выключить )) У нас компания об этом позаботилась. Закрыли любые меседжеры и внешнюю почту. Хабр забыли. Если бы еще сюда не заходил, был бы полный идеал. Но сюда стараюсь заходить до работы или после.
                              0
                              И по себе знаю, какая мука работать отвлекаясь. Устаешь гораздо больше от такого, чем концентрация и работа.
              • НЛО прилетело и опубликовало эту надпись здесь
                  +24
                  в оригинале было:
                  "...Their method is «pair programming»—where two people share one desk and one computer. One person is the «driver,» controlling the keyboard and typing in code. The other «navigates,» monitoring design and scanning for bugs."
                  так что — " не читайте до обеда советских газет" (с)
                  • НЛО прилетело и опубликовало эту надпись здесь
                    +4
                    >Каждый из партнеров придерживается своих стандартов кодирования, что вызывается бурные дискуссии и ужасно отформатированный код.
                    За это жестоко надо карать независимо от методики. Должен быть выработанный командный стандарт, которого все придерживаются.
                      0
                      Да, просто вопрос в том, как будет проходить адаптация этих стандартов. Бывает, что всем рассылается документ, где они описаны, можно парами программировать, можно просто проявить адекватность и всей командой его принять. Как говорил, парное программирование здесь может быть как инструмент для адаптации.
                        +1
                        Я немного про другое) Не имеет смысла вырабатывать этот стандарт в таких спорах. Это говорит о незрелости команды. Он должен быть (любым способом) выработан до начала работы над проектом.

                        Конечно, есть случаи, когда это неприминимо — я как-то занимался портированием уже написанного кода с одной платформы на другую (мобильные телефоны), но там вопросы _своего_ стиля и не возникали — нам приходил код начиная от пересыпанного си-измами, заканчивая чуть ли не индусским. После такого «разнообразия» к любому стилю относишься спокойно)
                          –2
                          Как на счет варианта, когда вы пришли на другой проект, а там другие стандарты?
                            0
                            Если это разработка нашей же команды (в которой принят единый стандарт), то выходит они нарушили соглашение, а значит надо дать по шапке.
                            Если же код писали другие люди, то тут уж как получится, я чужой код пытаюсь менять на наши стандарты, по мере правок того или иного модуля.

                            По поводу стандартов в команде — мы собрались всем отделом и обсудили что да как, поспорили немного, но в итоге пришли к единому способу кодирования. А вот все новые члены команды уже ставятся перед фактом.
                              0
                              Да, это интересно. А сколько человек у вас в команде? И сколько проектов идет одновременно?

                              Например, у нас на каждом проекте свои стандарты кодирования, которые исходят в основном от тимлида.
                                0
                                У нас команда небольшая, потому все так гладко прошло.
                                Но если в разных командах приняты разные стандарты, то это уже не стандарты, а бардак.
                                ИМХО конечно же, но я бы приложил усилия чтобы этого избежать.
                                  0
                                  А зачем этого избегать? Вот у нас идет сейчас 6 проектов, два из которых достались с уже написанным кодом. Стандарты кодирования на всех проектах разные, но внутри проекта все придерживаются единого.

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

                                      Даже если он и пойдет в другую команду, то к стандартам привыкает довольно быстро, главное что внутри проекта они едины.
                                        0
                                        Ну это все довольно спорный вопрос, не будем холиварить :)
                                        Я считаю если это стандарт, то он должен быть единым стандартом для всех.
                                          0
                                          Да, есть общие критерии качества кода, общие рекомендации. Например, есть msdn.microsoft.com/en-us/library/czefa0ke(v=vs.71).aspx

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


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

                                        P.S. Холивар по copy_n_paste оставим в стороне, ладно?
                                          0
                                          Неверно.

                                          Это ваше мнение. Я считаю иначе, хотя отчасти с вами соласен.
                                +1
                                >Как на счет варианта, когда вы пришли на другой проект, а там другие стандарты?

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

                              А создать файл стиля и установить всем в IDE — не? Не знаю, как там в остальных, но в Эклипсе это делается в несколько кликов. После чего он будет «помогать» не только во время написания, правильно расставляя отступы и прочее, но и позволяет привести к устаноленному стилю сразу весь файл при помощи магической комбинации Ctrl+Shift+F.
                                0
                                В VS тоже можно это сделать, а лучше это сделать для ReSharper'a. Я говорю про разные варианты, которые встречал на просторах нашей родины.
                            +2
                            Прверено на себе, процесс написания кода становится оч ржачным, эффект несомненно есть. Единственный минус — эти двое мешают остальным, потому что постоянно говорят и делают это громко и бороться с этим бесполезно.
                              –2
                              Да-да :)
                                0
                                Ну есть множество вариантов: уединиться в митинг-руме (при условии что есть ноут например), работать вечером, когда офис пустой ну и много вариантов. Не считаю это проблемой.

                                Вообще парное программирование это забавно, но продуктивность повышается не больше чем на 50%, по сути затрачивая те же человеко-часы выходит больше времени, нежели если бы оба программиста занимались одним и тем же. Только в некоторых ситуациях (когда надо сделать быстро и качественно и на человеко-часы плевать к примеру) этот подход имеет право на жизнь. Но это сугубо мое мнение и оно может не соответствовать истине.
                                  0
                                  Ну есть множество вариантов: уединиться в митинг-руме (при условии что есть ноут например), работать вечером, когда офис пустой ну и много вариантов. Не считаю это проблемой.

                                  Особенно если пара разнополая.
                                0
                                Когда у нас братом появился один компьютер на двоих нам просто пришлось практиковать именно эту методику. И это реально работало! Но хочу заметить что у нас на двоих был не только компьютер: у нас был общий интерес, мотивация, а самое главное одинаковый уровень знаний!
                                Я считаю что эта техника не применима для производства программного обеспечения. Очень трудно будет найти «пару» с теми же параметрами: мотивация, интерес, уровень знаний…

                                Я помню как мы радовались когда решали любую задачку… Это было просто офигенно… Спасибо что напомнили )
                                  0
                                  PS: Сейчас у нас один большой стол с двумя компьютерами. И хотя мы пошли по разным направлениям, я в веб а он в системное программирование, мы продолжаем обсуждать и дополнять идеи друг-друга, а самое главное ценить результаты… Никакой другой коллектив не даст мне такого «чувство локтя» как семейный. В прямом смысле )
                                    0
                                    Могу заверить, что уровень знаний не обязательно должен быть таким уж одинаковым. Совсем недавно парнокодили с коллегой, он лучше меня знает тонкости и плюшки RoR, а я лучше него знаю JS. В итоге — у нас вышла продуманная, красивая архитектура и реально полезный обмен опытом.
                                      0
                                      Продуманная архитектура она на то и «продуманная»… И вот сейчас у меня именно такая ситуация — мы с братом обдумываем идеи друг-друга прямо по горячему… Компы рядом, достаточно просто немного повернуть монитор… Но это не парное программирование. По статье это похоже на пятый анти-паттерн.
                                    0
                                    Постоянно практикую работу в паре. Потому что кроме этого варианта больше нет нормального способа передавать знания между работниками. Но это требует гораздо больших затрат усилий, чем работа в одиночку.
                                      +2
                                      В универе принимал участие в олимпиадах ACM, там работали втроем за одной машиной. Действительно помогает сконцентрироваться, когда кто-то рядом следит за кодом. Но постоянно в таком режиме работать очень тяжело.
                                        0
                                        В универе принимал участие в олимпиадах АСМ. Парного программирования реально было очень мало. Парный анализ и поиск решения — это да. А когда идея ясна вбивать чаще проще одному, чтобы сэкономить второму время на решение еще одной задачи.

                                        Меня в парном программировании больше всего смущает как раз отсутствие потока. Мне щас скажут, что мы, конечно, делали неправильное парное программирование, но я реально не представляю сколько нужно это «тренировать», чтобы был «парный поток». И я очень удивлен 8-му пункту статьи, для меня в этом месте наоборот большой минус.
                                          0
                                          Даже когда идея ясна, остается вероятность багов. Вот тут здорово помогал товарищ, сидящий рядом.
                                            0
                                            Это зависит от того, какая задача.
                                          +15
                                          Я просто не мог не оставить это здесь. Лучший видео курс по парному программированию от Bitbucket:
                                          .
                                            +3
                                            «Pull request» :)
                                              +4
                                              Элитные программисты, vip, почасово, ночь, свой коворкинг центр, xp, аджайл, скрам, парное кодирование, кодревью, возможно с другом, парами в стартапах
                                              0
                                              Мы в нашей фирме используем парное программирование, и могу подтвердить, что это действительно отлично работает. В общем-то, никаких секретов здесь нет: оно просто поддерживает высокую сконцентрированность практически весь рабочий день.
                                                +1
                                                Хочу сказать, что данный метод хорошо подходит не только для программирования. Нетривиальные моменты в системном администрировании тоже лучше работают в парном методе. Тут, разумеется, не «ревью», а человек, который во-первых остановит от глупости, во-вторых подскажет что делать дальше.

                                                Причина простая: у одного кусок мозга занят кнопками. Второй видит картинку чуть больше на расстоянии и имеет больше ресурсов на то, чтобы просто перебирать варианты. Если первый, замерший на пару минут, создаёт стресс «чего ждёшь?», то второй может минуту молчать, обдумывая какой-то тонкий момент.

                                                Плюс критический взгляд со стороны мешает халтурить.
                                                  +2
                                                  Да, ещё, по поводу исследовательских задач. Как раз в них, как мне кажется, парный вариант куда более интересный и эффективный. Потому что тут идёт не просто «code review», но и совместное обдумывание решения или вариантов/причин существования проблемы.

                                                  Столько раз было — «а посмотри-ка ты в (...), может там будет (...)» — и иногда так и было. Экономя при этом часы и часы бесплотных попыток.
                                                    0
                                                    По моим наблюдениям парное программирование наиболее эффективно при поиске решений багов или каких-то нетривиальных но небольших задачах. Исследование часто подразумевает много подготовительной рутины, которую делать в паре смысла нет.
                                                    0
                                                    Никогда не пытался внедрить эту практику в своей команде, но это происходит само собой регулярно. Вот примерный юз-кейс:
                                                    — %Username%, можешь глянуть? Что-то я не врублюсь.
                                                    — Ну ка… ээээ, да ты олень, все не так! Вот это сюда, а эту чушь вообще нахер сотри…
                                                    <прошло минут 10 >
                                                    — Ну вот, смотри как круто вышло!
                                                    — Ага
                                                      0
                                                      Это не паиркодинг, это просто хорошая команда, у нас тоже так)
                                                      Ещё, много разговоров с подобным кейсом часто происходит на курилке\на кухне.
                                                      0
                                                      Парное программирование также работает удаленно, используя связку Skype + VSAnywhere.
                                                        0
                                                        Я, сидя в Киеве, парно программировал с товарищем из Македонии. Пользовались TeamViewer. Очень хорошо получалось.
                                                        Важно не переключаться на свои окна, а наблюдать за парой.
                                                        +2
                                                        Больше всего понравилось описание анти-паттернов.
                                                        Я бы добавил еще парочку:
                                                        Халявщик: работает только один разработчик, второй тихо сидит рядом и просто думает о своем или даже спит.
                                                        Совершенный код: разработчики слишком увлекаются теоретическими обсуждениями макро- и микро- архитектур, тратя на это времени гораздо больше чем требуется.
                                                          0
                                                          Лет 10 назад пробывали мы этим заниматься, причём в области программирования для встроенных систем.
                                                          Не знаю как со скоростью, но что код получается чище и ошибок меньше, это точно!
                                                          Хочу только заметить, что Экстремальное программирование не ограничивается только работой в парах. В него много чего ещё входит, например написание тестов до начала программирования.

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое