iTechArt logo

Код в четыре руки, или что такое парное программирование

Development & QA

Парное программирование, или совместная работа двух программистов над одним кодом – не новая фишка, ей как минимум 20+ лет. Никита Пацкевич, Senior Software Engineer iTechArt, впервые столкнулся с этой техникой ещё будучи “джуном”, но и по мере развития своей IT-карьеры применял парное программирование не один раз. Решили узнать, насколько кодирование, в котором задействованы двое специалистов, влияет на рабочий процесс, какие условия нужны для того, чтобы “соображать на двоих”, и есть ли минусы у парного программирования.

Наш собеседник
Никита Пацкевич.jpg

Никита Пацкевич

Senior Software Engineer iTechArt

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

Что такое парное программирование?

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

Как и когда ты стал практиковать парное программирование?

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

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

Какие условия и оборудование/ ПО нужны для того, чтобы практиковать парное программирование?

Как я уже упоминал, в свое время мы с коллегой использовали один компьютер. Сейчас такое тоже возможно, но все же это вызывает некоторые неудобства. Кстати, один из стилей парного программирования называют distributed, но, как по мне, это не о стиле, а просто о способе организации, когда эксплуатируются несколько устройств и (или) специальные тулы и приложения. Давным-давно я использовал Slack, в IDE (интегрированная среда разработки) ранее были отдельные плагины для таких целей. Сейчас используются специальные программы. Например, для MAC OC такой программой является Tuple. Она позволяет делать видеозвонки, при этом второй человек может пользоваться клавиатурой и мышкой на удалённом девайсе. Такая же опция есть в Zoom. Для Windows это Drovio (так и позиционируется, как приложение для парного программирования). Из более старых, но все еще живущих подходов – использовать какое-нибудь приложение для звонков типа Skype и приложение типа Team Viewer.

Какие есть стили парного программирования? От чего зависит выбор стиля?

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

Есть стиль, который называют “guide tour”, он очень удачно вписался в такой формат собеседований, как live coding интервью. В нём есть условный “водитель”, который “рулит” всем процессом и пишет код, а “турист” - это просто слушатель/наблюдатель, который иногда добавляет какие-то комментарии и выносит какие-то вопросы на обсуждение. Такой стиль подходит не только для собеседований, но и, скажем, для работы со стажёрами. Достаточно 1-2 сессий по несколько часов (как правило, от 2 до 6), чтобы понять стиль мышления стажёра, зафиксировать пробелы.

Ещё 2 популярных стиля - “driver-navigator” и “driver-backseat navigator”. В первом из названных стилей, есть драйвер (человек, который будет писать код и при этом менее погружен в контекст) и navigator (человек который уже работал на проекте и знает чуть больше деталей). В такой модели драйвер реализует самостоятельно какую-то логику, а навигатор продумывает общую концепцию и следит за соблюдением архитектурного подхода. Этот стиль хорош для онбординга: даёт возможность члену команды глубоко погрузиться в проект.

Стиль “driver-backseat navigator”, или “штурман на заднем сидении”, предполагает большее влияние на процесс навигатора. В этом случае драйвер выполняет только функцию кодинга, а навигатор - указывает, что и как делать, вплоть до перехода навигации по папкам, названий классов и т.д. Я не приверженец такого стиля, поскольку с точки зрения обучения он более строгий и ограничивает обучающегося в получении собственного опыта.

Среди узкоспециализированных подходов есть еще и “пинг-понг”, он актуален только для программистов с примерно равными навыками и только для проектов, в который реализуется концепция TDD (test-driven development). Это когда один человек пишет тест, второй – имплементацию, которая пройдёт этот тест, и потом они меняются. Мне лично попробовать этот подход пока не представилось шанса.

Как парное программирование влияет на рабочий процесс? Выдели его ключевые особенности 

Основное предназначение парного программирования – обучение и профессиональное развитие участников процесса. Поэтому главное, что нужно сделать: во-первых, четко определить роли и план действий (например, когда задача считается завершенной); во-вторых, помнить, что споры должны идти на пользу, а столкновение мнений должно оставаться в рамках профессиональной этики. Чтобы так и было, важно, чтобы участники обладали достаточно высоким уровнем эмоционального интеллекта.

Интересен и момент с разделением ответственности. Персонально для меня выделять в парном программировании конкретного человека как ответственного за ту или иную ошибку несколько некорректно. Полностью избежать ошибок, конечно, невозможно. Обычно ответственность на том, кто делал имплементацию кода. То есть, в модели driver-navigator ответственность будет целиком лежать на навигаторе, поскольку его обязанность – следить за тем, как реализуются его указания. Если рассматривать guide tour, то там всё в руках у драйвера: “турист” не влияет на написание кода. Но если говорим про равноценное взаимодействие, как в “пинг-понг” стиле, то ответственность тоже паритетная.

Для каких проектов парное программирование идеально, а в каких не стоит его применять?

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

Какие ты видишь плюсы и минусы парного программирования?

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