При парном программировании два программиста решают задачу совместными усилиями, сидя плечом друг к другу за одним компьютером. Первый выступает «водителем», который печатает код на клавиатуре, а второй служит «штурманом» — он следит за тем, чтобы в программе не было ошибок, занимается архитектурой кода, планирует последовательность действий и думает о правильности кодирования в стратегическом масштабе. Такой способ разработки позволяет поддерживать более высокую концентрацию, стимулирует тщательно продумывать решение еще до его реализации и значительно снижает количество ошибок и повышает качество кода.
Почему мы используем в работе парное программирование?
Парное программирование имеет целый ряд достоинств:
- В сравнении с одиночным программированием оно позволяет программистам успешнее противостоять стрессу. Члены пары поощряют друг друга поддерживать высокое качество кода даже в напряженных условиях, когда может возникать желание написать «грязный» код для ускорения выполнения задачи.
- Парное программирование повышает качество кода, благодаря тому, что наблюдатель постоянно проверяет, следит за качеством и понятностью кода и задает уточняющие вопросы. Таким образом, удобочитаемость и понятность кода всех разработчиков повышаются до уровня кода лучшего программиста группы.
- Парное программирование ускоряет разработку системы. Как правило, пары пишут код быстрее, и большинство ошибок можно обнаружить сразу в процессе кодирования, а не тестирования. Соответственно в конце проекта группе приходится тратить намного меньше времени на исправление дефектов.
- Парное программирование усиливает взаимодействие внутри команды. Во время работы над проектом пары рекомендуется перемешивать, чтобы каждый разработчик в команде к моменту окончания проекта обладал глубокими знаниями о каждой из его частей.
- Парное программирование обеспечивает все остальные общие преимущества совместного конструирования, такие как распространение корпоративной культуры, обучение начинающих программистов и содействие совместному владению результатами работы.
Как сделать парное программирование более успешным
Чтобы извлечь из всех преимуществ парного программирования еще большую пользу, нужно соблюдать несколько простых правил:
№1. Поддерживайте парное программирование стандартами кодирования
Парное программирование теряет эффективность, если члены пары тратят время на споры о стиле кодирования. Чтобы избежать разногласий, нужно стандартизировать «несущественные атрибуты» программирования, чтобы разработчики могли сосредоточиться на стоящей перед ними «существенной» задаче и не отвлекались на согласование стилей.
№2. Не превращайте парное программирование в наблюдение
Парное программирование — это совместная работа, а не наблюдение одного разработчика за другим. Программист, который не занимается непосредственно написанием кода, должен принимать активное участие в разработке: анализировать код, планировать следующий этап, оценивать проект программы в целом, думать о том, как проводить тестирование и т.д.
№3. Определяйте задачи, которые целесообразно решать в парах
В большинстве компаний, использующих парное программирование, в итоге приходят к выводу, что в парах лучше выполнять не все, а только некоторые части работы. С реализацией простых фрагментов кода разработчик эффективнее справится самостоятельно. Кроме того, в некоторых случаях для написания наиболее сложного кода выгоднее посвятить 15 минут детальному проектированию на доске и затем программировать поодиночке.
№4. Постоянно меняйте состав пар и назначаемые им задачи
Как и при использовании других методик совместной разработки, одно из главных преимуществ парного программирования в том, что каждый из разработчиков изучает разные части системы. Регулярная смена состава пар помогает стимулировать обмен опытом и знаниями между всеми членами команды. Некоторые эксперты рекомендуют менять состав пар ежедневно.
№5. Старайтесь объединять в пару людей с одинаковым темпом работы
Когда один из партнеров работает слишком быстро, второму приходится стараться успевать за его темпом, что снижает качество анализа кода. В таком случае парное программирование не выполняет нужную функцию и начинает терять смысл. Член пары с более высокой скоростью должен снизить темп, либо пару нужно разбить и переформировать в другом составе.
№6. Оба члена пары должны хорошо видеть экран
Убедитесь в том, что оба разработчика хорошо разбирают код на экране. Неправильное расположение монитора или слишком мелкий шрифт могут снижать эффективность парного программирования.
Не стоит забывать и об эргономике — когда при передаче клавиатуры от одного члена пары другому, она остается в центре стола и каждому приходится наклоняться, оба быстро устанут и начнут терять концентрацию.
№7. Не объединяйте в пару людей, которые не нравятся друг другу
Как и в других совместных задачах, чем лучше отношения между членами пары и чем больше они соответствуют друг другу по характеру, тем выше будет результативность работы. Эффективность парного программирования зависит от того, насколько хорошо разработчики ладят друг с другом, поэтому объединять в пару людей, у которых не очень складываются отношения, бессмысленно.
№8. Не составляйте пару из людей, которые ранее не имели опыта в парном программировании
Максимальную выгоду от парного программирования можно получить, если хотя бы один из разработчиков в паре уже имел опыт парного программирования и сможет научить второго.
№9. Выбирайте лидера группы
Когда все члены команды хотят выполнить реализовать все задачи, используя программирование в парах, выберите ответственного за распределение задачи и контроль результатов проекта.
А вы используете парное программирование? Поделитесь своими секретами в комментариях!
Комментарии (20)
MadJackal
05.10.2017 13:21Вот меня всегда интересовал вопрос — если парное программирование эффективнее одиночного, то, по-идее, программирование в тройках должно быть еще более эффективным?
Никто не пробовал?
remzalp
05.10.2017 13:34+1Я не представляю, чем должен будет при этом заниматься третий, больше всего это будет напоминать ПМа.
Плюс сложнее будет составить команду из троих, чтобы работали с похожей скоростью и не было трений. Сбалансировать двоих проще :)
<шутка>сопьются же в поисках пика Балмера</шутка>
Desprit
05.10.2017 14:23Ну это как про ту яму — одному копать медленно, вдвоем быстрее, а если вдесятером, то уже и лопат на всех не хватает.
Где-то явно есть предел, вероятно, как раз таки на втором человеке имхо.
Danik-ik
05.10.2017 19:25Программирование — это настолько интимный процесс, что втроём — это, извините, извращение...
Никогда не работал в паре (так уж сложитось, ни в одном месте работы кроме меня вопрос организации техпроцесса разработки никого не волновал). Однако уверен, что для эффективной работы есть только два варианта: либо один партнёр, либо ни одного. Иначе это будет совещание, а не разработка.
Dmitry88
05.10.2017 13:35+4А вот если сзади будет стоять грузин с усами и трубкой
p.s. вы серьезно? а я люблю подумать, в носу поковыряться, музло слушать в процессе и т.д. И ненавижу, когда смотрят в мой экранkraidiky
05.10.2017 14:14+4Вот ещё парное программирование очень мешает ковыряться в носу, и раздумья длинной в 5 минут растягивать на часы. За это его и любят те, кто не любит чтобы программисты в носу ковырялись. :)
vildulv
05.10.2017 18:54Наверное парным программированием тогда лучше заниматься с тем человеком, с которым как минимум находишься в приятельских отношениях.
lpre
05.10.2017 14:46+5В сравнении с одиночным программированием оно позволяет программистам успешнее противостоять стрессу.
Вот это вряд ли. Скорее, парное программирование само является дополнительным источником стресса.
VMichael
05.10.2017 16:00+4Я пробовал применять парное программирование среди подчиненных.
Итог вышел такой, можно, для встряски, обмена опытом, ставить программистов парами на несколько дней.
Постоянно работать парами не эффективно и напряжно с психологической точки зрения.
Несколько дней люди еще работают и понимают для чего это. Постоянно работать парами — быстро накапливается психологическая усталось. И итоговая эффективность работы группы выше не становится (интуитивно, без каких либо метрик, которых точных мы так и не придумали).
dirkar
05.10.2017 16:01Если задача типовая и несильно сложная то смысла в этом нет.
А вот в сложных и нестандартных задачах это то что надо.
General_Failure
05.10.2017 16:02№8. Не составляйте пару из людей, которые ранее не имели опыта в парном программировании
Интересный совет. А где брать людей с таким опытом? Переманивать из других организаций, которые не следуют вашим советам?
tmn4jq
05.10.2017 16:06+2Все же ожидал дельных советов, а не очевидных вещей типа:
№6. Оба члена пары должны хорошо видеть экран
Сам я не особо люблю парное программирование, так как меня всегда сбивал с толку темп другого человека. Так что совет номер 5 нахожу хорошим.
Для меня работал такой хак: если вы работаете на ноутах, то можно просто сесть рядом каждый со своим ПК и изучать проблему. Когда у кого-то появляется дельная мысль, он ее озвучивает и показывает. Ведь необязательно же смотреть в один монитор, главное думать над одной задачей и делиться мыслями.
buldo
05.10.2017 18:59Стоит отметить сложности парного программирования в распределённой команде:
- При разнице часовых поясов в 2 часа время в паре всего 4 часа(пересечение рабочего дня 6ч + по часу на обед). При разнице поясов в 4 часа уже не может идти речи о сидении в паре.
- Сложно сконцентрироваться на коде, когда напарник не рядом, а в скайпе. Проблема №2 проявляется ярче.
Первую проблему можно как-то решить, если один из напарников согласится приходить на работу раньше.
Со второй проблемой сложно как-то бороться. Нужны ответственные разработчики.
Mishok8
05.10.2017 18:59+1Напоминает уроки информатики в школе, когда количество людей было в 2 раза больше, чем компов.
andrewzhuk
Спасибо за материал. Не знаю, мне кажется, что в универах имеет смысл внедрять подобные системы и начинать обучение с такого подхода.
Harr
вот это очень здравая мысль!
Nerlin
У нас в институте все так и работало — всю группу разбивали по 2-3 человека на практических и лабораторных занятиях. Люди учились работать вместе над одной проблемой, анализировать задачу и оценивать код, делясь почему так надо или не надо делать. Более опытный студент помогал развиваться отстающим, если им конечно было это интересно.