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

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

— — —

Впервые я попробовал удаленное парное программирование совсем недавно. Это было на буткемпе Lighthouse labs. Мне было интересно, почему это может быть так.

Думаю об этом сейчас. Я полагаю, это могло быть связано с тем, что технология, которая тогда была популярной, просто не считалась пригодной для парного программирования. Был скайп и тимвьювер. В то время Skype не был оснащен функцией совместного использования экрана, а teamviewer — это компьютерное программное обеспечение для удаленного доступа и удаленного управления, которое в основном было известно как инструмент для оказания технической поддержки.

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

Мои первые несколько заданий по парному программированию были очень короткими, они включали только написание функции, которая больше связана с решением головоломок, чем с реализацией части продукта. Таким образом, роли штурмана и водителей были распределены довольно быстро среди двойки. Человек, который не был уверен в решении, как правило, оказывался в позиции навигатора.

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

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

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

Тем не менее, нам пришлось использовать раздор, чтобы поделиться нашим экраном.

В то время как код vs live позволяет пользователям видеть курсор друг друга, из какого файла. Иногда это может отставать или мешать вам видеть активность хоста, если вы переходите к другой части проекта со своей стороны. А иногда необходимо увидеть и другие факторы, которые нельзя увидеть в визуальном обмене любовью в студии. Любые действия, связанные с использованием терминала, лучше всего рассматривать изначально с общего доступа к экрану, а не через тексты и тому подобное. Некоторые примеры включают использование git для переключения веток, слияния и т. д.

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

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

— —

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

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

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

В нашем случае на среднесрочной основе это был в основном неструктурированный стиль. Иногда штурманами были два человека и один водитель. Иногда 2 человека были драйверами, писали код в разных местах, а другой человек был наблюдателем, просматривая другие файлы в проекте, чтобы увидеть, чего не хватает. Иногда руль отдают другим людям, когда водитель слишком устает кодировать.

Использованная литература:

Бёкелер, Б., и Сиссеггер, Н. (2020 г., 15 января). О парном программировании. martinfowler.com. Получено 12 марта 2023 г. с https://martinfowler.com/articles/on-pair-programming.html.

Гиллис, AS (2021, 28 июня). Что такое парное программирование? Качество программного обеспечения. Получено 12 марта 2023 г. с https://www.techtarget.com/searchsoftwarequality/definition/Pair-programming.

Луи, К.М., и Чан, KCC (2006). Продуктивность парного программирования: новичок-новичок против эксперта-эксперта. Международный журнал исследований человека и компьютера, 64(9), 915–925. https://doi.org/10.1016/j.ijhcs.2006.04.010

Принципы Agile-манифеста. Манифест гибкой разработки программного обеспечения. (2001). Получено 10 марта 2023 г. с https://agilemanifesto.org/principles.html.