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

Понять суть парного программирования очень просто — это когда два специалиста работают в паре за одним компьютером. Такой метод работы встречается не только в разработке, но и в любой другой сфере. В исследовании «Explaining pair programming session dynamics from knowledge gaps» (Freie Universität Berlin) авторы изучали поведение пар c позиции недостаточности знаний. Знания они разделили на специфичные для разрабатываемой системы и общие (как вообще разрабатывать, паттерны, знание языка программирования и так далее). Рассмотрим оптимальные модели поведения в зависимости от типа недостающих знаний и конфигурации пары. парное программирование (pair programming) — методика, при которой весь разрабатываемый код пишется двумя программистами на одном компьютере.

Парное программирование: что это и почему его нужно освоить

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

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

Когда парное программирование работает

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

• ❌ У программистов должна быть примерно одинаковая квалификация.
• Они постоянно взаимодействуют, обсуждая проблемы, находя решения и разрабатывая творческие идеи.
• Наконец, если вы более опытный программист в паре, убедитесь, что большую часть времени находитесь на месте “штурмана”.
• Парное программирование — это одна из методик экстремального программирования, которая «выталкивает» одиночных разработчиков из зоны комфорта.

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

Динамика работы в паре

Таким образом, вы можете воспользоваться главным преимуществом парного программирования — высококачественным кодом — и одновременно использовать этот метод для обучения команды. Senior следует ответственно отнестись к парному программированию с Junior. Первым шагом будет признание самого факта, что сейчас вы в паре с джуном, а ему потребуется больше поддержки, внимания и направления действий. Учитывайте это еще при планировании, чтобы избежать давления сроков. Выбирайте подходящие (подходящие для Junior’а в данном случае) задачи, учитывая особенности и потребности, перечисленные выше. После сессии парного программирования обязательно проведите ретроспективу, пусть на пять минут, но хотя бы с одним улучшением, которое вы примените в следующую сессию.

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

Замена человека в паре ведет к смене рабочей обстановки

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

С помощью Continuous Integration/Continuous Delivery (непрерывной интеграции/непрерывной доработки) мы хотим снизить риск, часто внося небольшие изменения. В своем первоначальном определении это означает практику разработки Trunk Based Development (магистральная разработка). При такой разработке отложенные проверки кода еще менее эффективны, потому что изменения в любом случае немедленно попадают в главную ветку. Таким образом, парное программирование и непрерывная интеграция — две практики, которые идут рука об руку.

Чего избегать и как не завалить весь процесс? (v

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

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