Парное программирование

Парное программирование — это практика совместной работы двух программистов над одной и той же задачей на одной рабочей станции. Он был популяризирован благодаря включению его в методологию разработки программного обеспечения Extreme Programming (XP), которая позже стала частью популярного, хотя и противоречивого семейства методов разработки Agile.

Экстремальное программирование

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

Частью этих коротких циклов является множество циклов управления, коммуникации и планирования. Есть также две практики, о которых, скорее всего, слышали или использовали те, кто не знаком с экстремальным программированием: разработка через тестирование и парное программирование.

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

Роли

Невозможно понять парное программирование без понимания роли каждого программиста.

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

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

Цели

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

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

Преимущества

Практика парного программирования дает несколько дополнительных преимуществ, помимо простого создания высококачественного кода.

Все члены команды лучше знакомы с кодовой базой. Когда пары меняются каждые несколько дней, участники получают больше информации о разных частях кодовой базы и имеют возможность чаще думать о разных пользовательских историях.
Совместное использование как вектор расширения распространения институциональных знаний. Хотя это тесно связано с предыдущим пунктом, это одна из основных концепций экстремального программирования, согласно которой каждый коллективно владеет кодовой базой; никакая часть его не принадлежит никому в частности.
Предоставляет возможность экспертам наставлять новичков, а новичкам видеть, как опытные члены очень аутентично подходят к задачам. Это может быть хорошим способом адаптации новых членов команды, предоставляя им доступ к коду, который им может быть неудобно трогать самостоятельно.
Предоставляет новичкам возможность подвергнуть сомнению подход эксперта, что может побудить экспертов самим подвергнуть сомнению сложившуюся практику.
Команда может рассмотреть более широкий спектр решений, что снижает вероятность выбора плохого решения. Это одна из основных целей парного программирования. Консенсус также дает каждому участнику больше уверенности в том, что он может либо придерживаться текущего подхода, либо попробовать другой.
Короткий временной цикл обратной связи, ведущий к более высокому качеству кода. Это также является центральной целью парного программирования. Программисты делают угрожающее количество ошибок при наборе нового кода (посмотрите любое видео о профессиональном программировании, чтобы понять, что я имею в виду). Когда тесты не проходят или код выдает ошибку, это, скорее всего, результат какой-то небольшой ошибки, на поиск которой может уйти время. Немедленная проверка при вводе кода может выявить многие из этих ошибок. Также утверждается, что таким образом можно избежать очень больших ошибок.
Концентрация членов команды на задаче. Когда участники работают вместе, каждый член должен в некоторой степени адаптироваться к мыслительному процессу другого. Постоянное общение держит каждого члена на задании.
Изменение среды от конкуренции к сотрудничеству. Парное программирование требует, чтобы участники сдерживали свое эго и полностью сотрудничали, чтобы добиться успеха. Обмен идеями и объяснениями со всеми членами команды в сочетании с коллективным владением кодом меняет всю среду и усиливает чувство принадлежности. Такая рабочая среда очень продуктивна и доставляет удовольствие.

Критика

Как и в случае со многими принципами экстремального программирования, преимущества нелегко измерить. Это заставляет многих сомневаться в эффективности парного программирования в определенных ситуациях, организациях или в целом.

Неэкономичный. Некоторые утверждают, что преимущества качества кода не перевешивают значительного увеличения человеко-часов, затрачиваемых на кодирование в одиночку. В зависимости от проекта этот аргумент, вероятно, имеет смысл, но по мере роста проекта приемлемые причины жертвовать качеством кода быстро уменьшаются.
Межличностные проблемы. Культура парного программирования требует, чтобы люди ладили на более высоком уровне и могли работать исключительно профессионально. Убедить людей (особенно опытных программистов) перейти на такой стиль работы удается не во всех организациях.
Неоднозначность владения кодом. Некоторые люди считают, что владение кодом (идея о том, что только один человек отвечает за правильное функционирование фрагмента кода) не является обязательством для организации, и что возможность определить, кто за это отвечает, делает людей более ответственными.

Проблемы

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

Перекрытие времени. Люди должны быть доступны одновременно, чтобы выполнять парное программирование. Планирование сеансов даже за несколько дней вперед может снизить вероятность того, что один из партнеров не сможет работать. Другой альтернативой парному программированию является групповое программирование или моббинг, если четное количество программистов недоступно.
Вовлечение каждого человека. Отношение людей к парному программированию может быстро измениться, если они считают, что их не уважают, или у них есть проблемы с уровнем навыков партнера.
Согласование курса действий, когда точки зрения конфликтуют. Многочисленные стратегии способствуют продвижению процесса вперед, когда возникают разногласия по поводу того, что делать. Предложение другому партнеру возможности сначала обдумать свою идею или просто довериться другому партнеру часто обсуждается как решение этого типа конфликта. Упростить эту ситуацию может договоренность о том, какая идея партнера будет опробована первой.
Не превращая это в процесс наставничества. У менее опытного партнера может быть тенденция колебаться, давая обратную связь более опытному партнеру. Этого следует в равной степени избегать, так как более опытный партнер просто пытается продемонстрировать свои навыки. Обе ситуации сводят на нет цели процесса парного программирования.
Соблюдение этикета имеет первостепенное значение для успешного парного программирования. Есть много удобств, к которым программисты привыкли, но которые трудно включить в парное программирование, например, сочетания клавиш и скорость мыши (или ручное управление). Положение и перемещение мебели могут стать проблемой при обмене ролями. Даже личная гигиена может сильно повлиять на опыт и внимание участников.

Заключение

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