Перевод статьи «When to Pair Program and When to Go Solo».
Несмотря на все достоинства парного программирования, это не серебряная пуля. И чтобы получить максимальную пользу от него, нужно тренироваться.
Недавно я закончил читать книгу «Practical Remote Pair Programming». В аннотации автор — Adrian Bolboacă — обещает рассказать о структуре и организации парного программирования, коммуникации в паре и инструментах для успешной работы. При этом акцент сделан на дистанционной работе в распределенных командах.
Парное программирование — это непросто. Тем не менее, я уже некоторое время его практикую, пытаясь сформировать стойкие полезные привычки. Естественно, книга по этой теме привлекла мое внимание. А поскольку сейчас активно внедряется дистанционная форма работы (по крайней мере для программистов), книга с упором на удаленное парное программирование актуальна, как никогда.
Но знать, как происходит парное программирование, — мало. Нужно разбираться, в каких ситуациях оно поможет ускорить процесс разработки, а в каких — замедлит. В этой статье я кратко рассмотрю эти гипотетические ситуации. А если вы захотите получить более полное представление о предмете — прочтите книгу «Practical Remote Pair Programming».
Примечание. Я буду говорить о парном программировании. Однако, многие приемы парного программирования также применимы к моббингу — групповому программированию (от англ. mob — толпа, — прим. перев.).
Новичкам я бы посоветовал начинать с парных сеансов, а к групповым переходить, уже набравшись опыта.
В некоторых текстах вы также можете наткнуться на термин «ансамблевое программирование» — это более дружелюбное название для моббинга. В конце концов, мы не собираемся крушить код, как разъяренная толпа.
(Не)очевидные преимущества парного программирования
Вполне может оказаться, что не так сложно заниматься парным программированием, как убедить команду в его целесообразности. В этом разделе я расскажу, почему парное программирование — хорошая идея, и каким образом оно может сделать нас лучшими разработчиками.
Работа в паре — это наставничество
В начале моей карьеры меня знакомили с новыми проектами, а также принятыми в них соглашениями и другими важными вещами, как раз при помощи парного программирования. Я бесконечно благодарен всем своим коллегам, которые работали со мной в паре.
Парное программирование позволило мне вырасти в профессиональном плане на порядки быстрее, чем если бы меня предоставили самому себе. Дело в том, что это наставничество в чистом виде. Спустя некоторое время я тоже начал работать в паре с новыми коллегами, передавая им все полученные знания.
Как и в боевых искусствах, люди, имеющие более высокий ранг, несут ответственность за обучение людей с более низким рангом. Парное программирование — как раз про это. Поэтому лучшие пары часто формируются по принципу младший-старший. В идеале младший — это либо новый человек в компании, либо коллега, не знакомый с кодовой базой или доменом. Хорошие сеансы парного программирования получатся и с коллегой вашего уровня, но при таком раскладе роль наставничества будет меньше, а ваш рост будет не столь заметен.
В следующий раз, когда в вашей команде появится новичок, не просто выдавайте ему задачи полегче, а поработайте с ним в паре: так он быстрее подтянется до вашего уровня.
Парное программирование — это инструмент обучения
Как и многие другие, я начал свою карьеру с изучения информатики. На групповых занятиях по основам программирования, которые я посещал, всегда были практические упражнения. Часто мы решали поставленные задачи вместе, сидя за одним компьютером с одной клавиатурой.
В книге, которую я упомянул в начале статьи, автор говорит о четырех уровнях знания любой системы (в порядке возрастания):
- «Я ничего не знаю!» (новичок)
- «Я способен запустить эту систему» (средний уровень)
- «Я умею настраивать систему и исправлять ошибки» (продвинутый уровень)
- «Я владею этой системой!» (мастер)
Обычно вы поднимаетесь на эти уровни самостоятельно при периодической поддержке вашей команды. Но кратчайший путь к мастерству — работа в паре. При парном программировании вы быстрее разберетесь в системе, с которой работаете. И соответственно — быстрее сможете начать заниматься задачами, касающимися реорганизации и рефакторинга этой системы.
Поэтому, когда вам в следующий раз придется изучать сложную систему или домен, поработайте в паре с тем, кто знает их лучше всего.
Парное программирование — это обмен знаниями
Чем больше мы работаем в одиночку, тем больше подробностей о внутренней работе нашего кода узнаем. Делиться этими знаниями с помощью только лишь документации неэффективно и отнимает много времени, хотя это и важно для долговечности продукта.
Занимаясь парным программированием, мы можем естественным путем вырабатывать общие соглашения касательно разработки. Это избавит нас от необходимости долго просиживать на собраниях или просматривать массивные пул-реквесты.
Хорошая практика при этом — формировать пары из людей, работающих с разными частями системы. Например, над запросами к бэкенд-интерфейсам бэкенд-разработчик должен работать вместе с фронтенд-разработчиком. Успешное применение техник парного программирования разрушит невидимые стены в вашей команде.
Но имейте в виду, что общие знания должны быть еще и записаны. В противном случае они будут существовать лишь в вашей голове и голове вашего напарника.
Парное программирование — это социальное событие
Разработчики бывают самыми разными. Некоторые предпочитают фокусироваться под музыку из наушников с шумоподавлением. Другим, напротив, нравится компания коллег, с которыми можно обсудить сложные проблемы.
Я принадлежу к последним. Работая в одиночестве, я часто чувствую себя более напряженным и тревожным. Эти чувства начали усиливаться во время пандемии. Из-за длительной и непрерывной изоляции моя производительность значительно снизилась. Таким образом, для счастливой жизни и успешной работы мне нужно программирование в коллективе.
Парное программирование и моббинг (работа с тремя или более людьми) могут происходить и в рамках каких-нибудь мероприятий, организованных внутри сообщества. Яркий тому пример — хакатоны. Если сотрудники страдают от изоляции, организация социального мероприятия — прекрасный способ поднять настроение и подстегнуть рост инноваций.
В книге «Practical Remote Pair Programming» есть интересная история о социальном аспекте парного программирования:
«Я проводил одно мероприятие, в рамках которого программисты работали в парах. Во время их работы зашел генеральный директор. Он услышал об этом мероприятии, и ему стало любопытно, что происходит. Его никак особо не представляли, так что он присоединился к компании, поработал в паре и поучаствовал в обсуждениях, как и любой другой участник. Только после окончания этого мероприятия я узнал, что на самом деле он даже не был программистом».
Работа в паре подходит не только для разработчиков. В некоторых случаях можно поработать в паре с дизайнерами, тестировщиками, владельцами продуктов, менеджерами и даже с генеральным директором. Ведь если вы не можете объяснить свое решение гендиру, то какой в нем вообще смысл?
Распространенные ошибки, совершаемые при формировании пар
Вероятнее всего, вам уже случалось работать в паре, например, в университете или хотя бы в младших классах школы.
К сожалению, многие из нас в какой-то момент перестают это практиковать. Например, из-за негативного личного опыта. Или из-за политики менеджмента, убежденного, что быстрее всего фичи выпускаются при индивидуальной работе над ними.
Разумеется, парное программирование — это не фунт изюма. Чтобы оно проходило гладко и приносило максимум пользы, постарайтесь избегать следующих распространенных ошибок.
Работа в паре весь день
Непрерывная работа в паре может привести к утомлению и эмоциональному истощению к концу дня. Обычно я не могу дольше двух часов подряд говорить и писать код одновременно. Чтобы снять усталость, мне нужно отдохнуть не меньше 15 минут.
Необходимость постоянно поддерживать определенный темп работы, скорее всего, подорвет ваше самочувствие и ослабит интерес к парному программированию.
Если просто попытаться разбить восьмичасовой рабочий день на сеансы парного программирования, мы можем получить максимум 3-4 таких сеанса с короткими перерывами между ними.
На бумаге это выглядит эффективно, но на поверку оказывается утопией, как и любой другой подход, при котором пытаются максимально использовать рабочее время.
Помните, что непрерывная работа в течение всего рабочего дня — это прямой путь к больничным и выгоранию.
Лучше начать с сеансов парной работы в течение 25-30 минут подряд (в общей сложности 1-2 часа в день). При этом нужно делать короткие паузы и меняться ролями. Если задача завершена, можно сменить партнера. Я советую скачать приложение Pomodoro или использовать любой подходящий таймер, чтобы отслеживать время. Смена партнеров зачастую помогает поддерживать тонус, поскольку вам не приходится постоянно работать с одним и тем же коллегой.
Если вы будете эффективно распоряжаться временем работы в паре, в конечном итоге вы будете все меньше и меньше уставать, привыкая к этому новому способу работы. Когда привыкнете, можно будет постепенно увеличивать количество сеансов.
Я обнаружил, что могу заниматься парным программированием примерно 75% дня. Остальные 25% я оставляю на свободное время, когда я учусь, занимаюсь исследованиями или работаю самостоятельно.
У вас может быть другое идеальное соотношение, но не отводите на работу в паре 100% времени.
Парное программирование во враждебных или неизвестных водах
Работая в паре, мы ищем оптимальные решения, постоянно обмениваясь идеями. Какие-нибудь из наших оригинальных идей неизбежно покажутся безумными или неэффективными сразу после их озвучивания.
Следовательно, для парного программирования требуется психологически безопасное пространство, где над вами не смеются, что бы вы ни говорили.
Без психологической безопасности вы не сможете воплотить в жизнь свои лучшие идеи. В худшем случае вы будете молча следовать тому, что говорят другие, а это фактически сведет парное программирование к индивидуальному.
Если в вашей команде есть какие-то конфликты, нужно сперва разрешить их, а уж потом разбиваться на пары.
Или вот другая ситуация. Предположим, никто в группе не знает друг друга: так иногда бывает в быстро меняющихся консультационных проектах. В этом случае вам следует подождать, пока команда не пройдет этап формирования и не привыкнет работать как единое целое.
А если вся организация разработки такова, что постоянно приходится «тушить пожары», а люди ненавидят работать друг с другом, то… просто подайте заявление об уходе.
Обязательное ревью кода, написанного в паре
Некоторые разработчики, привыкшие к работе в сильно бюрократизированных, процедурно-ориентированных и иерархических культурах, категорически заявляют, что парное программирование не заменяет формальное код-ревью. Это аргументируется утверждением, что третий человек со свежим взглядом сможет выловить ошибки, допущенные вами и вашим напарником.
Тут можно спросить, как же этот третий разработчик, не имеющий контекста или глубокого понимания проблемы, сможет лучше проверить ваше решение?
Асинхронные методы работы привели к идее, что к проверке кода обязательно нужно привлекать «посторонних». Но на самом деле коллеги, понимающие контекст и проблему, проведут код-ревью куда лучше. А кто же эти коллеги? Это ваши напарники!
Предположим, принятая у вас процедура требует внешней проверки кода, несмотря на то, что вы и так работаете в паре.
В худшем случае вам сначала придется дождаться, пока третий разработчик отвлечется от своей текущей задачи. Причем этому человеку, перед изучением написанного вами кода, придется превозмочь все негативные воздействия переключения контекста. Наконец, он представит вам свои отзывы (зачастую ошибочные) и вернется к своей предыдущей задаче. Это резко снижает производительность команды и увеличивает время выполнения задач.
Вместо этого попробуйте работать в парах, ориентируясь на непрерывную доставку. Спроектируйте, внедрите, изучите, протестируйте и, наконец, разверните свое решение. Похлопайте друг друга по плечу (можно виртуально), выпейте кофе и переходите к следующему заданию.
Я эффективно завершал пользовательские истории с десятками подзадач в течение одного-двух дней, не создав при этом никаких серьезных дефектов.
Работа с неясными требованиями
Если ваша команда не имеет четкого понимания проблемы или домена, парное программирование не приносит результатов. Скорее всего, вы в конечном итоге будете в течение нескольких минут с открытым ртом смотреть на описание задачи (зачастую сформулированное клиентом или владельцем продукта), прежде чем перейти к чему-нибудь полегче.
К счастью, работа в паре не всегда связана с программированием, потому что и решение проблем не всегда сводится к написанию кода. Вы можете поработать с владельцем продукта или руководителем группы и вместе написать высококачественные требования.
Парное программирование в комплекте в с плохими практиками написания кода
Работа в парах неэффективна, когда плотный график вынуждает вашу команду ежедневно срезать углы и таким образом накапливать технический долг.
А вот если вы приняли решение улучшить качество вашей кодовой базы, можно постепенно начинать разбирать завалы и реорганизовывать код, работая попарно.
Несколько практических советов
В этом разделе я кратко опишу небольшие приемы, которые помогают мне в парном программировании (как в удаленном, так и в офисе).
Делайте ансамблевые коммиты
Работая в паре, мы обычно используем одну и ту же кодовую базу. Это означает, что инструменты контроля версий не могут точно определить, кто что сделал. В принципе, указывать конкретного автора коммита не всегда важно, ведь за все решения отвечает вся команда. Тем не менее, рекомендуется отдавать должное авторам там, где это необходимо.
Это можно сделать с помощью ансамблевых коммитов. Вы просто указываете имя вашего напарника и адрес его электронной почты в футере сообщения коммита. См. пример ниже.
Не все провайдеры систем контроля версий отображают эту информацию правильно. Но GitHub поддерживает этот подход при указании нескольких авторов. Это отличный способ отдать должное своему напарнику. Это также помогает другим разработчикам понять, кому впоследствии можно задавать вопросы по этому коммиту.
Распределяйте роли
Помимо написания информативных сообщений коммитов, делайте сами коммиты пораньше и почаще. При формировании пар также можно сразу распределять роли (с учетом ротаций).
Когда один из разработчиков не знаком с надежными методами тестирования, при работе в паре особенно эффективна разработка через тестирование.
В таких случаях один разработчик пишет провальный тест. Другой разработчик пишет код для успешного прохождения этого теста. После успешного прохождения теста вы делаете коммит и приступите к рефакторингу решения. Когда код станет достаточно чистым и при этом все еще будет успешно проходить тест, сделайте коммит еще раз. При необходимости, прежде чем пушить коммиты, вы сможете их объединить.
Используйте подходящую IDE
Это дело вкуса, но я считаю одними из лучших инструментов для парного программирования Code With Me от JetBrains и Visual Studio Live Share от Microsoft.
Также можно расшарить сеанс терминала через мультиплексор, например tmux. Но если мой напарник не чувствует себя в терминале, как рыба в воде, и не привык пользоваться Emacs или Vim, я бы предпочел пойти другим путем.
Я нахожу Visual Studio Live Share наилучшим инструментом для сеансов парного программирования. В большинстве случаев я делюсь своей локальной средой с помощью функции переадресации удаленных портов. Мой напарник может перейти по тому же адресу http://localhost:<port> и увидеть среду разработки в реальном времени.
Я также могу предоставить общий доступ к своему терминалу, чтобы напарник видел, какие команды я использую в своем процессе разработки. Всего несколько щелчков мыши — и удаленное парное программирование становится почти таким же простым, как работа за одним компьютером.
IDE, ориентированные на удаленное парное программирование, вполне можно применять и локально, если у вас хорошо настроена сеть и нет больших задержек. Многие не любят делиться клавиатурой (чужие микробы!). В таких случаях отличный вариант — расшарить среду разработки и работать со своих ноутбуков.
Расшаривание экрана для контекста
Но не стоит полагаться лишь на IDE: иногда нужно показать напарнику точную ситуацию. Убедитесь, что вы показываете правильную вкладку браузера (особенно при работе над задачами фронтенда), чтобы ваша команда могла видеть, что происходит.
Для расшаривания экрана вполне подойдут платформы, которыми мы обычно пользуемся для проведения удаленных собраний, — Google Meet, Zoom и Microsoft Teams.
Инвестируйте в оборудование
Если собираетесь заняться парным программированием, убедитесь, что у вас есть приличная веб-камера, наушники и микрофон.
Никогда не используйте встроенный микрофон и динамики вашего ноутбука. Звук набора текста и эхо голоса напарника будут отвлекать и в конечном итоге испортят впечатление.
Можно использовать высококачественные системы для создания подкастов, но также можно обойтись и бюджетными наушниками (только не самыми дешевыми). Для подбора наушников попробуйте провести в них сеанс парного программирования в течение часа. Если болят уши, поменяйте наушники.
Вам не всегда нужно будет включать веб-камеру. Порой это может сделать парную работу более приятной, но не всем нравится, когда камеры постоянно включены. При необходимости обсудите это со своим напарником перед началом работы.
Если вы решите включить веб-камеру, отрегулируйте освещение, чтобы не выглядеть черным силуэтом на фоне яркого дневного света. Выключите все источники за спиной и включите свет спереди (не слишком яркий), чтобы ваше лицо лучше выделялось.
Обеспечьте стабильное сетевое соединение
Из-за плохой связи ваш голос может заикаться или стать похожим на голос робота, а это отвлекает. Однако для парного программирования вовсе не обязательно тянуть оптоволокно на 1 ГБ. Главное, чтобы соединение было стабильным, задержки — низкими, а пропускная способность — достаточной для аудио и видео. Членам вашей семьи во время вашей работы не стоит смотреть Netflix в другой комнате.
Если вы используете Wi-Fi, подойдите как можно ближе к маршрутизатору. По возможности подключайте кабель Ethernet. Если текущая задача не требует использования VPN-соединения или других прокси, отключите их.
Всегда ли целесообразно работать в паре?
В этой статье я рассказал о преимуществах и подводных камнях парного программирования, а также дал советы по организации процесса, которые помогут вам сделать совместную работу более гладкой. Но остался очень важный вопрос: когда следует сделать выбор в пользу именно парного программирования?
Решиться не всегда легко. По моему опыту, некоторые задачи лучше выполнять в одиночку. Среди прочих, к ним относятся:
- развертывание сборок и запуск скриптов
- документирование существующих функций и написание простых инструкций
- проверка, можно ли воспроизвести обнаруженный баг
- выполнение рутинных задач, которые вообще следует автоматизировать.
А вот в ситуациях, когда требуется выровнять уровень знаний в команде, изучить новые концепции или решить сложные задачи, парное программирование будет отличным способом работы.
Давайте сделаем мир разработки лучше, работая вместе.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
