Обзор ответов на семь самых популярных замечаний о недостатках парного программирования, как со стороны junior-разработчика, так и со стороны senior-разработчика.
Парное программирование мешает углубленной работе
Достаточно тяжело добраться до корня проблемы, взвесить все за и против и выбрать действительно наилучшее решение, пока кто-то постоянно заглядывает через ваше плечо и указывает, что печатать.
Сразу следует задаться вопросом: что такое “углубленная работа”?
“Это профессиональная деятельность, выполняемая в состоянии концентрации. Она доводит когнитивные способности до предела, а прилагаемые усилия создают новую ценность и повышают мастерство. При этом их будет трудно повторить”.
Групповой мозговой штурм неэффективен в решении проблем с программным кодом. Поиск решения происходит гораздо эффективнее, если отдельные люди приходят на встречу с уже продуманными заранее идеями.
Самая сложная задача в программной инженерии — придумывать креативные решения с учетом ограничений (стоимость, технический долг, требования заказчика и так далее). Лучше всего заниматься подобным в одиночестве.
Тем не менее парное программирование весьма полезно на этапе создания конечной реализации идеи (написания кода), то есть уже после того, как решение было продумано и согласовано — особенно при работе с частями кодовой базы, в которых вы далеко не эксперт.
Не всем разработчикам подходит парное программирование
Согласно анекдотам и стереотипам, среди разработчиков много интровертов. Они предпочитают менее напряженную среду, а вот работа в паре иногда чрезмерно социально активна — отличный аргумент в пользу того, чтобы не работать так на постоянной основе. Но это не значит, что интроверты ненавидят общение или не любят работать в команде.
В современную эпоху “вечной работы из дома” программирование в паре как раз способно обеспечить контролируемое ежедневное социальное взаимодействие. В противном случае многие разработчики-интроверты могли бы провести весь день, ни с кем не разговаривая и уставившись в экран, что не очень хорошо для психического здоровья.
Следует сделать вывод, что работа в паре лучше подходит одним разработчикам и меньше подходит другим, но важна и сплоченность команды, в которой всем сотрудникам комфортно и все друг другу доверяют.
Потеря новыми разработчиками уверенности в своих навыках
В процессе совместной работы со старшим разработчиком младший может почувствовать себя неполноценным. Подобное происходит в случае, если старший разработчик просто говорит младшему, что делать, не объясняя никакой фундаментальной логики. Или, что еще хуже — старший разработчик просто оставляет младшего наблюдать за процессом разработки, выполняя всю работу самостоятельно.
Хотя это не вина старшего (он видел код тысячу раз и не хочет тратить время зря), младший разработчик в паре может почувствовать себя настолько некомпетентным, что постесняется задавать какие-либо вопросы. Это может привести к потере уверенности в себе, в то время как на самом деле, вероятно, что младшему разработчику просто не хватает знаний о нескольких ключевых частях технической информации.
При неправильном подходе неудачный опыт может повлиять на представление разработчика о работе в паре до такой степени, что она может стать для него пустой тратой времени. Но вот при выражении сочувствия со стороны старшего разработчика и его уверенности в том, что младший не постесняется задавать вопросы, парное программирование окажется исключительно ценным опытом.
Программировать в паре — утомительно
Ежедневная восьмичасовая работа в паре даже у экстраверта вызовет дискомфорт. Большинство разработчиков также согласятся с тем, что работа в паре часто оказывается чрезмерно утомительной.
К счастью, работодатели редко указывают восьмичасовое парное программирование в расписании, такое встречается разве что в отделах разработчиков, изо дня в день создающих посредственные CRUD-приложения: это места, в которых никто не захочет работать.
Учитывая, что парное программирование требует больше энергии, его следует использовать только там, где оно явно приносит пользу: при разработке чего-то сложного, вам в любом случае потребуется время на размышления и планирование.
Так или иначе, необходимо помнить, что цель — найти баланс, а не сама работа в паре как таковая в любых количествах.
Парное программирование бесполезно для старших разработчиков
Существует мнение, что обучение — односторонний процесс, который помогает младшим разработчикам войти в курс дела, не принося особой пользы старшим инженерам.
Хотя многие разработчики соглашаются с этой идеей, представление пары как “старший/ младший” — откровенно вредно, так как упускается из виду множество возможностей использования парного программирования.
Два опытных разработчика, специализирующихся на разных частях стека (frontend и backend), извлекают пользу из совместной работы, одновременно затрагивая обе области веб-разработки.
Учитывая, что в прямые обязанности старшего разработчика входит помощь младшим, “трату времени” на передачу знаний без особой отдачи следует воспринимать просто как часть работы.
Работа в паре избыточна
Зачем использовать двух разработчиков для задачи, которую может решить один? В любом случае, при парном программировании одновременно только один человек пишет код.
В таком случае работа в паре действительно бессмысленна: если задача легко решается одним разработчиком, то нет необходимости в паре.
Но есть задачи, где 1 + 1 равно 3.
- Когда вы не можете найти решение проблемы самостоятельно.
- При обучении нового разработчика, недавно присоединившегося к команде. Конечно, новенький всегда может воспользоваться ссылкой на документацию, но помощь сотрудника всегда ускоряет ознакомление с кодовой базой.
- Отладка. Второй разработчик лучше, чем метод утенка.
Если общая скорость работы команды гораздо важнее, чем индивидуальный вклад в разработку, то парное программирование становится достаточно эффективным.
Отсутствие права собственности на код
Наличие нескольких разработчиков, работающих над одним фрагментом кода, снижает ответственность. Больше не ясно, кто несет ответственность, если код впоследствии сломается.
Существуют разные мнения на этот счет. Например, считается, что разработчик, который делает Pull Request, несет окончательную ответственность и сохраняет авторские права. Второй разработчик просто помогает ему.
В конечном счете, команда должна достаточно заботиться о своем приложении, чтобы любой ценой избегать внедрения плохого кода и никогда не использовать сложные правовые ситуации в качестве оправдания разработчика.
Выводы
Парное программирование характеризуется как издержками, так и уникальной пользой: не стоит относиться к данной практике как к панацее и не стоит её избегать. Работа в паре — всего лишь один из инструментов в наборе средств, помогающих разработчикам в процессе работы.
У большинства разработчиков недовольство парной работой связано с тем, как руководство использует её, а не с самой практикой. Как разработчики, мы хотим, чтобы нам доверяли, но с таким же успехом парное программирование случайно может заставить почувствовать себя так, будто что за нами следят. Эффект может возникнуть из-за того, что парное программирование сводится к простой помощи друг другу.
В целом, парное программирование чрезвычайно полезно: было бы ошибкой никогда не работать в паре. Тем не менее при неправильном подходе оно способно разрушить моральный дух и заставить разработчиков задуматься о смене коллектива.
Читайте также:
- Комментарии: за или против?
- Что стоит знать дизайнеру перед первым хакатоном
- 4 типичные ошибки программиста, которые видны лишь с позиции руководителя
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Chris The Data Guy: Why Everybody Hates Pair Programming
