Парное программирование: показания к применению и правила этикета

20 мая
Алексей Мироненко, Senior Java-разработчик, тимлид
Парное программирование: показания к применению и правила этикета
Алексей Мироненко, опытный Java-разработчик, уже восемь лет руководит распределенными техническими командами. Алексей верит, что софт объединяет людей, а программисты способны контролировать рабочие процессы и сам софт, который создают. В его проекте активно применяется парное программирование — когда и как стоит использовать эту технику,  — в статье Алексея.

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

Основы техники ПП

Сам прием заключается в том, что двое, а иногда и больше разработчиков одновременно решают общую задачу, сидя за одним компьютером. Поскольку клавиатура одна на двоих, одному из пары достается роль «драйвера», или ведущего. Второй выполняет роль штурмана-навигатора, он определяет направление работы на более абстрактном уровне и постоянно следит за кодом, который пишет его коллега.

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

Существует разновидность парного программирования, известная как пинг-понг, адаптированная для разработки через тестирование. Но лично я близко знаком как раз с классическим вариантом, когда один пишет, а второй рассказывает, куда будем двигаться дальше. 

Дистанционное ПП

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

Когда ПП будет полезно?

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

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

Доказано, что параллельное программирование значительно повышает качество кода — примерно на 15 %. Хотя успех использования приема будет, в первую очередь, зависеть от конкретных людей и от их опыта в его применении. Качество кода, думаю, возрастает прежде всего потому, что мы получаем не просто больший объем анализа кода, но получаем его на гораздо более ранних этапах.

Когда ПП работать не будет?

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

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

Побочный эффект

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

Наладить коммуникации

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

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

Правила общения 

Жестких правил здесь, конечно, нет, а общие рекомендации выглядят предельно простыми:

  • не бояться говорить вслух;
  • быть вежливым и доброжелательным;
  • не впадать в поучительный тон. 

Рекомендую очень простой трюк. Если видите, что сидящий рядом человек делает не то, то нужно, сосчитайте до 5, а потом и до 10. Если вам кажется, что он упорствует в своем заблуждении, нужно об сказать. Мгновенная реакция на ошибку может сбить настрой напарника. Вполне возможно, дойдя до точки с запятой, он вернется в начало и исправит неточность, которую и сам сразу заметил.  

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

Еще один сложный навык — отказаться от лишних допущений. Когда мы говорим с другими людьми, часто совершаем коммуникационную ошибку: думаем, будто знаем, что они намереваются сделать или сказать. Такие догадки часто затмевают очевидные факты, которые как раз служат отправной точкой для конструктивного разговора. Допустим, если вас перебили, вряд ли стоит говорить напарнику: «Ты, конечно, считаешь себя самым умным!» Гораздо полезнее заметить: «Я собирался поправить эту строчку через две секунды. Ты заметил важную ошибку, но согласен ли ты, что меня перебил?» Сухие факты: было сделано справедливое замечание, но ошибку вы и сами собирались исправить. Дальше можно решить, как избегать таких ситуаций в будущем, если вас они напрягают. 

Перспектива роста

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

Кстати, первые программистки, работавшие с машиной Eniac, действовали как раз в паре. Решили, что только так ее можно быстро освоить, а были они совсем неглупыми людьми.

Отношение бизнеса

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

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

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