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

Ян Ашенкампф

Старший технический директор

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

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

Парное программирование сокращает время на рефакторинг, потому что тот проходит в моменте, уменьшает количество багов и избавляет от дополнительной работы: оформление бага в багтрекинге, передача на исправление, воспроизведение разработчиком, поиск в коде, исправление, повторное тестирование и так далее. А ещё помогает находить неочевидные проблемы, решать сложные задачи и реже отвлекаться на ленту в YouTube.

Исследование «The Costs and Benefits of Pair Programming» показало, что такой подход:

• снижает количество багов в коде на 15%;
• помогает писать код объёмом примерно на 20% меньше. 

При этом растёт стоимость разработки. Согласно всё тому же исследованию — примерно на 15%. По личному опыту — выше. Поэтому методику лучше применять точечно, вместе с конкретными отделами или членами команды.

Для прокачки

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

Ещё можно посадить вместе двух джунов. Они в любом случае будут учить друг друга чему-то — каждый в своей сфере. И станут вместе искать ответы на незнакомые вопросы и решать сложные задачи. Но такой паре всё равно нужен более опытный ментор на подхвате.

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

На дежурствах

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

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

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

Для онбординга

Если на работу вышел новый сотрудник, вы можете посадить его два месяца изучать Confluence. Или отправить «подмастерьем» к действующему разработчику. Поначалу он будет смотреть, чем занимается коллега. Потом — начнёт писать сам, под надзором. И, наконец, самостоятельно возьмётся за задачи.

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

Для отбора

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

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

Это полезно и для самих соискателей, потому что помогает понять, с какими задачами придётся разбираться, интересно ли им, подходит ли темп работы.

Как проходит работа

Есть несколько распространённых методов программирования в паре. Разберём их подробнее.

Штурман и водитель

Команда прорабатывает будущий проект на бумаге, в Miro — или любом другом удобном инструменте. Затем первый участник, «водитель», пишет код и проговаривает действия, а «штурман» проверяет решение. Спустя некоторое время, например, полчаса, разработчики меняются местами.

При обучении желательно, чтобы код писал тот, кто понимает меньше.

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

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

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

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

Пинг-понг

Этот стиль хорошо сочетается в TDD, и его удобно использовать для удалённой работы. Процесс выглядит так:

• первый разработчик пишет тест;
• второй — код под него;
• второй разработчик пишет новый тест;
• первый — код под него;
• и так далее.

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

Кроме того, «пинг-понг» помогает паре сдружиться (особенно это важно на удалёнке), потому что вы постоянно ставите друг другу задачи, помогаете за счёт тестов и так далее.

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

Напарников нужно менять примерно раз в одну-две недели, по нескольким причинам:

• разработчики успевают рассказать и объяснить друг другу всё, что знают сами;

• долгая работа в паре изматывает — из-за постоянного контроля и более интенсивного темпа;

• спустя две недели люди начинают уставать друг от друга;

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

Как начать программировать в паре

1. Подготовить место. Разработчикам нужно большое пространство, чтобы каждый чувствовал себя свободно. А также 2–4 монитора, две клавиатуры и достаточно мощное железо, чтобы ничто не тормозило.
2. Заранее выбрать IDE и инструментарий, который понятен обоим. Если один работает только в Vim, второй — в Visual Studio Code, при программировании в паре одному всегда будет сложно адаптироваться к незнакомой среде. Это затормозит процессы и может вызвать у пары стресс. Также важно сразу определить code style.
3. Спланировать график работы. Программисты в паре должны работать и делать перерывы в одно и то же время, чтобы никто не выпадал из контекста. Иначе вся ответственность ляжет на одного человека, а второй будет просто присутствовать рядом и ничему не научится. 
4. Убедиться, что менее опытный напарник готов учиться и делать то, что не умеет. Нельзя брать в пару человека, который говорит: «Я люблю писать код для генерации отчётов и ничего, кроме этого, делать не хочу. Ни изучать сетевой стек, ни перехватывать трафик, ни заниматься производительностью, ни копаться в конфигурационных параметрах. Уйдите от меня подальше».
5. Договориться о правилах открытости и убедиться, что напарникам комфортно друг с другом. 
6. Обговорить, что программирование в паре — временно: «Не волнуйся, ты всё ещё программист, 80% времени ты занимаешься формулами. Но в оставшиеся 20% сможешь поделать что-то новое с напарником».

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