Само собой разумеется, что следить за дорогой во время вождения, как правило, является хорошей практикой. Хотя можно одновременно водить машину и читать карту, вероятность того, что что-то пойдет не так, выше. В конце концов, первоначальная задача эксплуатации тяжелой техники требует внимания к деталям.
Наличие другого человека, читающего карту, позволяет водителю сосредоточиться на текущей задаче; вождение автомобиля. Кроме того, штурман может сосредоточиться на своей текущей задаче и давать водителю более четкие инструкции.
Точно так же кодирование с другим разработчиком может принести те же преимущества.
Очевидно, что программирование и вождение автомобиля — это две очень разные операции, но у них есть одно большое сходство. Если вы не будете осторожны, последуют проблемы. К счастью, если вы отводите взгляд от своего кода, это не приведет к катастрофе, но если вы не сконцентрируетесь, даже незначительная ошибка может прокрасться, что приведет к серьезному сбою в вашем приложении.
—Начать парное программирование—
Что такое парное программирование?
Как следует из названия, парное программирование — это метод разработки программного обеспечения, при котором два разработчика работают вместе на одной рабочей станции. Целью этой стратегии является:
Быстрая разработка более качественного кода при одновременном снижении рисков и распространении знаний в организации — Александра Альтатера — Что такое парное программирование?
Это обычная практика, когда один разработчик выступает в роли водителя, который пишет код, а другой выступает в роли навигатора или наблюдателя,отслеживая, что водитель печатает, а также ищет способы решения своей проблемы. Разработчики часто меняются ролями, давая каждому возможность взглянуть на код свежим взглядом. Этот метод повышает качество кода и минимизирует риск ошибки.
Плюсы и минусы парного программирования
Эта тема вызывает большие споры в отрасли. Существует четкое различие между разработчиками, которые с энтузиазмом применяют эту практику, и теми, кто считает ее пустой тратой ресурсов. Оба являются действительными мнениями, в которые мы углубимся дальше:
Плюсы:
- Разрабатывает качественный код.
- Укрепляет межличностные коммуникации внутри компании.
- Улучшает боевой дух команды. Одно исследование показало, что 96% людей, практикующих парное программирование на работе, получают от своей работы больше удовольствия, чем индивидуальное программирование.
- Прогресс в навыках тайм-менеджмента.
- Возможность для разработчиков делиться знаниями и методами.
- Проверка кода на ходу.
- Два способа мышления лучше, чем один.
Минусы:
- Расходы. Существует часто цитируемая оптимальная оценка в 15% накладных расходов для парного программирования по сравнению с независимым программированием. Хотя первоначальная программа сопряжения может стоить дороже, она продлит срок службы кода, что приведет к меньшим затратам времени и денег на его исправление и поддержку в дальнейшем.
- Устойчивость. Парное программирование не предназначено для постоянного применения.
- Переход от драйвера к навигатору может привести к «переключению контекста», что приведет к потере времени.
- Различные уровни мастерства. Программирование старшего разработчика с младшим разработчиком будет кардинально отличаться от программирования младшего с младшим.
Что нужно и что нельзя делать в парном программировании
Подобно изучению кода, парное программирование требует практики. Мой первый опыт парного программирования удался. Группа была привлекательной, уважительной и даже глупой, что создавало веселую среду обучения. С другой стороны, мой второй опыт парного программирования столкнулся с трудностями, которых я не ожидал. Каждый раз это будет по-разному, так что хорошо разберитесь в том, что можно и чего нельзя делать в парном программировании.
Навигация по парному программированию может иметь свои проблемы. Крайне важно осознавать и практиковать следующие моменты при программировании с другим разработчиком, чтобы создать среду, в которой люди чувствуют себя взволнованными, услышанными и уважаемыми.
Дос:
- Часто меняйте роли. Разрешите каждому разработчику переключаться между вождением инавигацией. Исследование было проведено компанией Dr. Sallyann Freudenberg, который отображал парные команды программистов и то, сколько они поменялись ролями. Одна команда не поменялась ролями, что привело к недостатку внимания и общения. Другая команда меняла роли 2–3 раза в день, в результате чего штурману было трудно переключиться на должность водителя. Чаще меняйтесь ролями!
- Делайте перерывы.
- Будьте внимательны к своему коллеге-разработчику.
- Ожидайте кривую обучения. Это новый навык, на освоение которого требуется время.
- Держите диалог открытым между обеими сторонами. Если у вас есть вопросы, задавайте их. Если вы устали, сообщите об этом своему партнеру.
- Будьте уязвимы. Это навык, который требует времени для развития. Парное программирование требует доверия и уязвимости, что, в свою очередь, создает безопасное пространство для творчества и решения проблем.
Уязвимость — место рождения инноваций, творчества и изменений — Брене Браун — Сила уязвимости TED Talk
Не:
- Как навигатор, не занимайтесь микроуправлением и не переусердствуйте при исправлении простых опечаток. Парное программирование — это командная работа, и важно предоставить водителю пространство для размышлений.
- Не будьте нетерпеливы. В статье, написанной Бригиттой Бокелер и Ниной Сиссеггер, предлагается правило 5 секунд, которое позволяет навигатору ждать 5 секунд, прежде чем что-либо сказать, если они заметят ошибку. В течение этого времени водитель уже может понять ошибку.
- Не позволяйте одному человеку доминировать в пространстве парного программирования. Каждый участник должен чувствовать себя комфортно, чтобы вносить идеи.
- Не заставляйте никого чувствовать себя плохо, задавая вопросы. У всех разный уровень мастерства. Никто не должен стыдиться того, что не понимает концепцию.
Рекомендации для будущих учеников
- Как новый ученик, будьте открыты для опыта парного программирования, когда у вас есть возможность. Приложите все усилия, прежде чем решить, для вас это или нет.
- Будьте открыты для того, чтобы облажаться или показаться глупым. Вот как мы учимся.
- Держите диалог открытым между вами и вашим партнером.
- Оставьте место для других мнений. У кого-то может быть другой способ делать что-то, и это не значит, что он неправильный. Это может быть именно то, что нужно вашему коду.
- Будьте проще и не забывайте, что вы и ваш партнер в одной команде!
Последние мысли
К сожалению, нет явного победителя в том, должна ли каждая команда внедрить парное программирование или нет. По моему личному мнению, я считаю, что это имеет невероятные преимущества, которые не может предложить самостоятельное программирование.
Парное программирование дает возможность озвучивать свои логические мысли во время отладки или решения проблем. Если какая-то часть становится сложной для озвучивания, есть большая вероятность, что там скрывается препятствие для написания кода.
«Если вы не можете сказать это просто, значит, вы недостаточно хорошо это понимаете». - Альберт Эйнштейн
Позволяя водителю и навигатору сосредоточиться на назначенной им задаче, парное программирование способствует более высокому уровню внимания и качества вашего кода, избегая ненужных катастроф кодирования.
Хотя поначалу реализация парного программирования может быть дорогостоящей, долговечность вашего кода будет расти, что приведет к тому, что в будущем на исправление кода будет потрачено меньше денег.
Наконец, парное программирование подходит не для каждой команды или каждого человека, но вы обязаны исследовать его потенциал ради себя и своей команды.
Удачного кодирования!
Процитированные работы
- Альянс, Agile. Парное программирование: действительно ли это работает? 4 марта 2021 г. https://www.agilealliance.org/glossary/pairing/#:~:text=Pair%20programming%20is%20an%20important,algorithm%2C%20code%2C%20or%20test.
- Кокберн, А. (2002) Гибкая разработка программного обеспечения. Аддисон-Уэсли, Бостон
- Макдэвид, Сэм. Плюсы и минусы парного программирования. 25 февраля 2021 г. https://www.verypossible.com/insights/the-pros-and-cons-of-pair-programming.
- Плонка Л., Сегал Дж., Шарп Х., Линден Дж. (2011) «Совместная работа в парном программировании: управление и переключение». Гибкие процессы в разработке программного обеспечения и экстремальном программировании (XP 2011). Спрингер, Гейдельберг, стр. 43–59.