О парном программировании говорят не так часто. Если кратко, то это методика, когда над одним участком кода, проектом работают два разработчика. Обычно один из них пишет код, второй комментирует и помогает. Такая методика не панацея, но она многое даёт как компании, в которой отлажены такие процессы, так и самим специалистам. Об этом говорим под катом.
Почему стоит использовать парное программирование?
В первую очередь потому, что оно значительно экономит время на рефакторинг. Когда над одним участком работают два программиста, в коде становится меньше багов. Соответственно, сокращается время на отладку, поскольку уходит сразу несколько итераций вроде оформления багов в багтрекинге, взаимодействия с тестерами, исправления, повторного тестирования.
Вот основные преимущества методики:
Повышается скорость работы. Разработчики гораздо меньше отвлекаются на побочные задачи, общение с коллегами (кроме напарника) и разного рода кофе-брейки и перекуры. Прокрастинации при таком способе нет.
Увеличивается скорость отладки. Два человека могут гораздо быстрее найти проблему в коде, чем один. У одного глаз может быть «замылен», а второй быстро обнаружит баг.
Растёт качество кода. Если программист, который кодит, допускает ошибки или качество кода падает, то второй это замечает и помогает исправить ситуацию.
Передача опыта и обучение. Парное программирование позволяет оперативно обмениваться знаниями и опытом, лучше использовать инструментарий и др.
Согласно данным ряда исследований, с одним из которых можно ознакомиться вот по этой ссылке, парное программирование позволяет снизить количество багов примерно на 10-20% плюс сократить объём самого кода. Кроме того, опрошенные в ходе исследования разработчики заявили, что они более уверены в результате, чем в случае одиночной работы. Такой ответ дали 95% опрошенных программистов.
Как всё это реализуется на практике
Команда проекта не начинает работу просто так — сел и поехал. Сначала задача обсуждается, намечается план (лучше на бумаге или в электронном виде), а потом уже все приступают к работе. Что касается пары разработчиков, то они каждые полчаса или час меняются ролями. Один пишет код, его роль принято называть «штурманом», второй этот код чекает, мониторит и составляет стратегию работы, его роль — «ведущий».
Рабочий процесс выглядит следующим образом:
у разработчиков должна быть чёткая задача
её нужно разбить на небольшие цели, которые фиксируются
пара должна меняться ролями, смена активности всегда помогает в работе
каждый должен заниматься задачей в рамках своей роли: если разработчик пишет код, то «стратегически» должен мыслить «штурман», а «ведущий» — работать с тактикой и деталями
Такой способ эффективен и в случае работы двух специалистов с примерно равным опытом, и в случае пары «новичок — опытный сотрудник». Речь идёт об опыте работы в самой компании, понятно, что пара «джун — мидл» хорошие результаты вряд ли покажет. Второй случай хорош для обучения и онбординга. Но именно знания и опыт работы с определённым стеком должны быть примерно равными.
Если серьёзный проект ляжет на плечи пары «джун — мидл», то джун будет чувствовать себя, образно говоря, машиной для ввода символов, а второй быстро начнёт нервничать, поскольку неопытный разработчик может не знать многое из того, что нужно для работы.
Кстати, пара «джун — джун» тоже возможна. И она даже необходима, если задача не самая сложная. Дело в том, что в процессе работы оба программиста неплохо прокачают навыки и знания. Речь здесь как о хард-, так и софт-скилах.
Кроме того, рекомендуется раз в пару недель или месяц пары менять, поскольку сотрудники могут просто уставать друг от друга. За пару недель разработчики рассказывают друг другу почти всё, что знают сами, поэтому для получения новых знаний лучше давать сотрудникам возможность общаться с новыми членами команды.
Очень важно позаботиться и о состоянии рабочего места. В частности, жизненно необходимо:
планировать время совместной работы: кодить и отдыхать нужно в одно и то же время, за рабочим местом оба программиста должны присутствовать одновременно
учитывать опыт и предпочтения: у пары должен быть опыт работы с выбранным IDE и стеком технологий, в противном случае один будет путаться в новой для себя среде, а второй — получать стресс в чистом виде
убедиться в совместимости участников: сотрудники должны быть в хороших отношениях друг с другом, ведь если у них есть проблемы с личным общением, хорошей работы не получится
подготовить рабочее место: оба программиста должны чувствовать себя комфортно за рабочим столом — должно быть несколько мониторов, две клавиатуры и производительный компьютер
Что делать, если в компании не практикуется парное программирование?
Если разработчику хочется попробовать такой метод, но в компании его не практикуют, можно попробовать участвовать в чемпионатах и соревнованиях. В этом случае проблемы нет. Разработчики, которые принимают участие в таких мероприятиях, получают огромное количество опыта и дополнительные знания, плюс здорово прокачивается социальный скил.
