Содержание:
Когда парное программирование работает
Парное программирование сокращает время на рефакторинг, потому что тот проходит в моменте, уменьшает количество багов и избавляет от дополнительной работы: оформление бага в багтрекинге, передача на исправление, воспроизведение разработчиком, поиск в коде, исправление, повторное тестирование и так далее. А ещё помогает находить неочевидные проблемы, решать сложные задачи и реже отвлекаться на ленту в YouTube.
Исследование «The Costs and Benefits of Pair Programming» показало, что такой подход:
- снижает количество багов в коде на 15%;
- помогает писать код объёмом примерно на 20% меньше.
При этом растёт стоимость разработки. Согласно всё тому же исследованию — примерно на 15%. По личному опыту — выше. Поэтому методику лучше применять точечно, вместе с конкретными отделами или членами команды.
Для прокачки
Парное программирование работает, когда код пишут специалисты с разным уровнем знаний: сеньор и мидл, мидл и джун, сеньор и джун. Так, один учит другого. И вместе с тем — сам лучше разбирается в системе.
Ещё можно посадить вместе двух джунов. Они в любом случае будут учить друг друга чему-то — каждый в своей сфере. И станут вместе искать ответы на незнакомые вопросы и решать сложные задачи. Но такой паре всё равно нужен более опытный ментор на подхвате.
Сеньоров я бы ставил в пару только в том случае, если они хорошо разбираются в разных системах и технологиях. Если это два специалиста, глубоко погруженных в одну тему, скорее всего, они будут спорить и придираться, а не писать код.
На дежурствах
Поддержка — это сложно. Нужно знать множество разных сервисов на таком уровне, чтобы грамотно обработать любой запрос, решить проблему пользователя, пофиксить баг, выкатить релиз и так далее.
Но людей, которые идеально разбираются во всех сервисах компании, мало (или вообще нет). Поэтому можно ставить в пару дежурных, которые знают разные системы. Так специалисты специалисты в процессе работы обучат друг друга.
Кроме того, при таком подходе исключается ситуация, когда клиент звонит в поддержку, а в ответ слышит «У меня обед, позвоните позже».
Для онбординга
Если на работу вышел новый сотрудник, вы можете посадить его два месяца изучать Confluence. Или отправить «подмастерьем» к действующему разработчику. Поначалу он будет смотреть, чем занимается коллега. Потом — начнёт писать сам, под надзором. И, наконец, самостоятельно возьмётся за задачи.
На следующем этапе новичка можно отправить ко второму разработчику, с другим уровнем и другими компетенциями. Потом, если нужно, — к третьему. Так, он быстрее погрузится в задачи, изучит сервисы, с которыми придётся работать. И параллельно сблизится с командой.
Для отбора
У джунов не только самый быстрый рост, по сравнению с разработчиками других уровней, но и самая жёсткая конкуренция. И парное программирование можно использовать для того, чтобы посмотреть на специалистов не в «стерильных» условиях собеседования, где обсуждаются алгоритмы по книжке Кнута, а при работе над реальными задачами. И найти самого перспективного.
На одном из предыдущих мест работы, мы применяли такой подход, называли его «демо-день». Перед тем как взять одного из кандидатов на работу, разбивали всех на пары, давали типовую задачу и наблюдали, как люди с ней справляются, насколько их поведение на интервью отличается от поведения при реальной работе и так далее.
Это полезно и для самих соискателей, потому что помогает понять, с какими задачами придётся разбираться, интересно ли им, подходит ли темп работы.
Как проходит работа
Есть несколько распространённых методов программирования в паре. Разберём их подробнее.
Штурман и водитель
Команда прорабатывает будущий проект на бумаге, в Miro — или любом другом удобном инструменте. Затем первый участник, «водитель», пишет код и проговаривает действия, а «штурман» проверяет решение. Спустя некоторое время, например, полчаса, разработчики меняются местами.
При обучении желательно, чтобы код писал тот, кто понимает меньше.
Строгое парное программирование похоже на стиль «штурман-водитель», но в этом случае первый полностью контролирует процесс и диктует, что нужно делать. Если у «водителя» появляется идея, он занимает место «штурмана».
При таком подходе понятно распределение ролей в паре. И он лучше всего подходит для онбординга и обучения — потому что возле новичка всегда есть более опытный напарник, который подробно объясняет, что делать. Кроме того, оба человека максимально вовлечены в процесс: одному в любом случае приходится писать, второму — думать.
Если один из напарников «выпал» из процесса: залип в ленту новостей, отвлёкся на разговор с кем-то — его лучше посадить на место «водителя» и снова переключить его внимание на работу.
Пинг-понг
Этот стиль хорошо сочетается в TDD, и его удобно использовать для удалённой работы. Процесс выглядит так:
- первый разработчик пишет тест;
- второй — код под него;
- второй разработчик пишет новый тест;
- первый — код под него;
- и так далее.
Такой подход кажется довольно весёлым: постоянный челлендж с немедленной гратификацией и быстрым вознаграждением. Получил мини-задание, быстро выполнил, быстро проверил, порадовался, что всё хорошо.
Кроме того, «пинг-понг» помогает паре сдружиться (особенно это важно на удалёнке), потому что вы постоянно ставите друг другу задачи, помогаете за счёт тестов и так далее.
Но если нужно обучить новичка, это работает плохо — чтобы писать грамотные тесты и давать конструктивную обратную связь, нужен уже опытный разработчик.
Напарников нужно менять примерно раз в одну-две недели, по нескольким причинам:
Как начать программировать в паре
- Подготовить место. Разработчикам нужно большое пространство, чтобы каждый чувствовал себя свободно. А также 2–4 монитора, две клавиатуры и достаточно мощное железо, чтобы ничто не тормозило.
- Заранее выбрать IDE и инструментарий, который понятен обоим. Если один работает только в Vim, второй — в Visual Studio Code, при программировании в паре одному всегда будет сложно адаптироваться к незнакомой среде. Это затормозит процессы и может вызвать у пары стресс. Также важно сразу определить code style.
- Спланировать график работы. Программисты в паре должны работать и делать перерывы в одно и то же время, чтобы никто не выпадал из контекста. Иначе вся ответственность ляжет на одного человека, а второй будет просто присутствовать рядом и ничему не научится.
- Убедиться, что менее опытный напарник готов учиться и делать то, что не умеет. Нельзя брать в пару человека, который говорит: «Я люблю писать код для генерации отчётов и ничего, кроме этого, делать не хочу. Ни изучать сетевой стек, ни перехватывать трафик, ни заниматься производительностью, ни копаться в конфигурационных параметрах. Уйдите от меня подальше».
- Договориться о правилах открытости и убедиться, что напарникам комфортно друг с другом.
- Обговорить, что программирование в паре — временно: «Не волнуйся, ты всё ещё программист, 80% времени ты занимаешься формулами. Но в оставшиеся 20% сможешь поделать что-то новое с напарником».
Для обоих разработчиков программирование в паре должно быть бонусом, а не повинностью. Поэтому людям должно быть комфортно работать вместе.
