Навык парного программирования, все более популярный метод гибкой разработки программного обеспечения, отделен от общего навыка разработки программного обеспечения. Многолетний опыт работы в ПП не является ни необходимым условием, ни достаточным для успешного парного программирования.
Эти выводы формируют общие выводы статьи «Два элемента навыков парного программирования», принятой для 43-й Международной конференции по разработке программного обеспечения (ICSE 2021), которая должна была состояться в Мадриде в мае, но теперь будет виртуальной. Франц Зирис и Лутц Прехельт из Института информатики Свободного университета Берлина решили исследовать элементы навыков парного программирования путем качественного анализа сеансов парного программирования, ища паттерны проблемного поведения, чтобы концептуализировать ключевые элементы того, что «хорошие» и «плохие» пары делают по-разному.
Чтобы заполнить некоторый фон, парное программирование (PP) — это когда два программиста работают вместе на одной рабочей станции. Один из них, водитель, пишет код, в то время как другой, наблюдатель или навигатор, просматривает каждую строку кода по мере ее ввода. Два программиста часто меняются ролями.
PP-это одна из техник экстремального программирования, XP. В статье цитируется Кент Бек, автор книги «EXtreme Programming EXplained: Embrace Change» (1999) и человек, который более или менее изобрел XP, характеризуя PP как:
“диалог между двумя людьми, пытающимися […] программировать (и анализировать, проектировать и тестировать)”, который “является тонким навыком, на который вы можете потратить всю оставшуюся жизнь, чтобы стать хорошим”
Зиерис и Прешельт комментируют это в своей книге:
Бек видит много преимуществ в этой практике, таких как более высокое качество кода за меньшее время. Однако он не вдается в подробности аспектов “навыка”, лежащего в основе этих преимуществ; он просто намекает на важность коммуникации и координации.
Они также отмечают:
Большая часть исследований в области парного программирования, по-видимому, строится на предположении, что PP не требует каких-либо особых навыков, помимо общего опыта разработки программного обеспечения.
Их исследование направлено на изучение того, какие навыки необходимы для успешного парного программирования и как они соотносятся с общими навыками разработки программного обеспечения с общей целью понять, чем отличаются «хорошие» и «плохие» сеансы парного программирования, проанализировав сеансы PP из хранилища более 60 ежедневных сеансов PP от 13 компаний, включающих аудио, веб — камеру и скринкаст, а также анкеты до и после сеанса, заполненные разработчиками. Они приложили все усилия, чтобы выбрать сеансы из репозитория с участниками пар, которые регулярно занимались парным программированием в течение многих лет, и теми, кто был новичком в этой практике, а также с участием опытных разработчиков программного обеспечения и новичков.
Два элемента навыка парного программирования, упомянутые в названии статьи и которые, как утверждают исследователи, не зависят от навыков разработки программного обеспечения,:
Единение Хорошие пары умудряются оставаться вместе, то есть создавать и поддерживать общую ментальную модель на протяжении всего сеанса. Они обнаруживают и устраняют соответствующие расхождения в понимании друг другом своей задачи, состояния работы, системы программного обеспечения и разработки программного обеспечения в целом.
Хорошие пары сочетают краткосрочные цели, такие как выявление дефекта или внедрение новой функции, и долгосрочные цели, например, устранение пробелов в знаниях любого участника.
Они также идентифицируют три анти-паттерна, проблемные поведенческие паттерны, которые влияют на один или оба из этих элементов:
Теряясь в сорняках, оба партнера остаются вместе как пара, но теряют из виду, какие темы стоит развивать.
Потеря партнера Один член пары слишком много внимания уделяет задаче и слишком мало объясняет.
Утопление партнера Один член пары объясняет слишком много, что может нанести ущерб Единству и целесообразности пары.
Исследователи приходят к выводу, что предыдущий опыт ПП сам по себе не объясняет полезное и проблемное поведение, и отмечают, что для понимания и выяснения влияния личных стилей разработчиков, их повседневной формы и их опыта парного программирования в целом или с конкретным партнером потребуются лонгитюдные исследования с одними и теми же разработчиками в течение более длительных периодов времени.
Парное программирование (2007) Источник: Википедия