Речь идет о разговоре между новичком (Джерри) и опытным сотрудником (Том), которые оба работают разработчиками в ИТ-фирме.

Джерри: Привет, Том, я новичок в этом гибком мире, и с того момента, как я присоединился, я заметил, что люди здесь очень серьезно следят за Agile. Я пытаюсь изучить методы гибкой разработки, не могли бы вы помочь мне понять некоторые из них, например, парное программирование, что это такое? Это действительно полезно? И каковы его преимущества и есть ли какие-то антипаттерны?

Том: Привет, Джерри, добро пожаловать в мир Agile !! Конечно, я помогу вам разобраться в «парном программировании» 😊 😊

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

Том: позвольте мне упростить вам задачу. Парное программирование следует гибкой методологии, в которой 2 программиста работают вместе, разделяя обязанности.

Джерри: Что это за водитель и навигатор? Я имею в виду, почему нам нужно 2 программиста для написания одного и того же кода? Разве это не приведет к большему вовлечению разработчиков, один разработчик может завершить код, а другой может одновременно работать над другим фрагментом кода? 😕

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

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

Джерри: Понятно !!! Но разве водитель всегда будет держать клавиатуру для написания кода, а навигатор всегда будет перемещаться? Когда они меняются ролями?

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

Джерри: Прекрасно !! Звучит неплохо, но есть ли проблемы, связанные с парным программированием?

Том: Да, довольно часто наблюдается, что, играя роль водителя-навигатора, навигатор может легко отвлекаться, что влияет на качество кода и косвенно на производительность драйвера.

Джерри: Да, но вы только что рассказали о программировании для настольного тенниса, которое может помочь в решении этой проблемы, не так ли?

Том: Да, теперь вы понимаете концепцию парного программирования 😊

Джерри: Да !! но я хочу знать, есть ли другие преимущества, кроме эффективного кода?

Том: Да, у парного программирования есть много других преимуществ. Когда вы объединяетесь в пары, водитель и навигатор обмениваются обширными знаниями. В своих прошлых проектах я заметил, что спаривание помогло ускорить процесс адаптации, так как совместное использование контекста становится намного проще, когда мы программируем в паре.

Джерри: Ага !! Согласен с тобой.

Джерри: Итак, Том, я понял, что парное программирование довольно эффективно, но есть ли связанные с ним плохие практики, которых я могу избежать?

Том: Плохая практика означает, что вы говорите о антипаттернах парного программирования?

Джерри: Ага !! Антипаттерны парного программирования.

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

Сродство пары: если г-н X хочет соединяться с г-ном Y каждый раз и не готов выполнить ротацию пары, это приводит к сродству пары. Это вредит маневренности команды и сводит на нет цель парного программирования. ⚔️

Захват клавиатуры: когда г-н X не передает клавиатуру г-ну Y и, таким образом, не позволяет ему писать код, что приводит к захвату клавиатуры. Есть разработчики, которые развивают эту привычку хвататься за клавиатуру надолго, что может привести к тому, что другой разработчик почувствует себя потерянным и, таким образом, не внесет никакого вклада в кодовую базу.

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

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

Джерри: Ой! это кажется весьма полезной информацией. Я буду изо всех сил стараться избегать этих антипаттернов при парном программировании 😊.

Джерри: Том, у меня в голове один вопрос. Иногда есть очень небольшая часть работы, которую нам нужно выполнить как часть истории, и я сомневаюсь, что для такой небольшой работы будет полезно спаривание?

Том: Верно !! Вам нужно или не создавать пары, решается в зависимости от задачи, которую пара должна выполнить. Если задача слишком мала и спаривание не требуется, вы можете выполнить прагматическое спаривание. Pragmatic Pairing выполняется, когда работа слишком мала. В прагматической паре вы обсуждаете идеи и проблемы со своей парой, а затем вы оба одновременно выполняете сольную работу. Если вы где-то застряли, вы снова обратитесь за помощью / обсудите со своей парой и продолжите работать отдельно.

Джерри: Ааа !! Приятно, что я узнал много нового о парном программировании.

Том: Джерри, я рад, что вы поняли концепцию парного программирования, но просто запомните эти факты, когда будете создавать пары:

  • Всегда обсуждайте идеи / подходы со своей парой, прежде чем начинать работу над пользовательскими историями.
  • Используйте монитор, и оба разработчика должны сосредоточиться на одном и том же мониторе.
  • Поощряйте открытое общение.
  • Задавайте вопросы, если не понимаете.
  • Обращайтесь за помощью, когда вам нужно.
  • Делайте короткие перерывы, когда это необходимо вам или вашей паре.
  • Через некоторое время поменяйтесь ролями.
  • Делайте обычные парные ротации.
  • Возьмите на себя ответственность за код и дайте такой же шанс своей паре.

Джерри: Большое спасибо, Том, за то, что поделился концепциями парного программирования. Я постараюсь следовать этому в своих будущих проектах.

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