Парное программирование

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

Парное программирование

Мне кажется, чтобы просто объяснить, как устроено парное программирование, можно привести в пример раллийные гонки. Там есть водитель (драйвер) и штурман (навигатор). Водитель сосредоточен непосредственно на управлении автомобилем. Штурман же контролирует на каком участке мы сейчас едем, и подсказывает пилоту о предстоящих поворотах и трамплинах.

Так же и в парном программировании.

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

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

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

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

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

Обучение новичка

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

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

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

Шеринг знаний и ликвидация Башни

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

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

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

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

Ликвидация Башни знаний имеет еще один неочевидный для многих плюс. Кроме децентрализации знаний о конкретных фичах и участках проекта, мы еще и снижаем нагрузку на разработчика, вокруг которого эта самая Башня изначально и была построена. Ведь чаще всего, если в команде есть незаменимый специалист, ему приходится часто работать в режиме на износ, с овертаймами, без выходных во время релизов и вообще, быть доступным 24/7. Все это постоянное давление рано или поздно приводит к профессиональному выгоранию или, в лучшем случае желанию найти более спокойную работу.

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

Решение сложных задач

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

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

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

Смешанные задачи

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

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

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

Итого

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

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

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