Причины парного программирования


13

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

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

Как человек, близкий к уровню разработки, который, очевидно, не вполне может понять из книги, которую я бросил, или из вики-страницы на эту тему ... с позиции высокого уровня управления, каковы преимущества парного программирования при работе со Scrum или Agile окружающая среда?


2
Я думаю, что это полезно в очень специфических ситуациях. Но, как общая модель развития, она вроде бесполезна.
Райан Кинал

4
Это может зависеть от программного обеспечения, которое может окрашивать ваш взгляд. Если у вас много маленьких виджетов и вы каждый день работаете над разными небольшими частями программного обеспечения, это, скорее всего, бесполезно. Это становится чрезвычайно полезным, когда вы имеете дело с крупной корпоративной системой, где разработчики должны учитывать каскад в системе, созданный их функциональными возможностями. Написание одного класса, который воздействует на данные, используемые в более чем 30 различных местах, обычно лучше рассуждать двумя людьми, у которых будут разные психические процессы для этого. Это как метод Монте-Карло для поиска перед дефектом.
Джимми Хоффа

@JimmyHoffa Итак, основной мыслительный процесс заключается в том, что если мы найдем ошибки еще до того, как они попадут в приемочное тестирование, мы сможем значительно сократить время, затрачиваемое на проверки кода / тестирование в дальнейшем?
Джефф Лангемайер

3
@JeffLangemeier На самом деле это нечто большее; Если вы видите недостатки в дизайне раздела A1 подсистемы A до того, как A1 даже написаны из-за естественного дискурса, который возникает между двумя разработчиками в процессе реализации подсистемы A, вы не только экономите время, которое будет потрачено на исправление раздела A1, и разделы A5 и A7, которые зависят от A1 (или находят ошибки в этих зависимых разделах из-за каскада от исправления A1), вы экономите время, не записывая этот плохой раздел в целом. Да, это сокращает время тестирования, но таким образом еще больше сокращает время разработки.
Джимми Хоффа

@MartinWickman Это не дубликат. В вашем связанном они действительно искали минусы, хотя название спрашивало за и против. Кроме того, более полный ответ плюсов был дан в этом; до такой степени, что это полезно для сообщества, даже если оно близко к другому.
Джефф Лангемайер

Ответы:


25

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

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

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

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

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


+1 за отличный ответ. Мне все еще сильно не нравится эта идея, но вы хорошо представляете ее преимущества.

Мне нравится отрезок твоего клипа, сэр, это объяснение на самом деле делает это чувство жизнеспособным.
Джефф Лангемайер

9
Я предпочитаю гибридную модель, где спаривания являются более специальными, исходя из текущих потребностей. Кроме того, бывают моменты, когда работа в одиночку более эффективна, а времена, когда работа с партнером - лучше. Быть вынужденным в постоянные пары кажется мне произвольным и негибким.
2012 года

Очень хороший ответ Я также программист в гибкой команде, и мы много работаем в паре. Вначале мы тоже были скептически настроены, мы думали, что работать в одиночку - лучший путь. Затем, в какой-то момент в развитии команды, мы наложили парное программирование. НЕ производился производственный код, если не была запрограммирована пара. Это было искусственное применение концепции сопряжения, но это очень помогло команде. Наконец, после того, как мы все привыкли к технике и друг другу, мы изменили наш стиль, и мы работаем в режиме ad-hoc, и в основном, когда реализация более сложна или подвержена ошибкам.
Паткос Чаба

@jfrankcarr, никто даже не предлагал постоянные пары; Я не уверен, откуда у вас возникла эта идея. (Обратите внимание, что в этом ответе конкретно упоминается «когда нужно чередовать пары».) Наша команда обнаружила, что очень плохой идеей является объединение одних и тех же людей в пары более одного дня или двух; ты начинаешь садиться в колею. Некоторые команды вращаются каждые полтора часа (ссылка в формате PDF).
Джо Уайт

3
  1. Меньше ошибок в конечном коде (эффективность)
    Не полностью заменяет обзоры кода, но очень эффективна для того, чтобы все исправить на ранних этапах. Существует исследование, которое указывает в этом направлении.

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

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

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

3

Быстрый ответ: большинство преимуществ и затрат опубликовано в Википедии, однако, давайте посмотрим на это с разных сторон.

Я хотел бы упомянуть конкретные случаи преимуществ парного программирования, которые применяются к среде разработки Agile / Scrum, взятые из поста в блоге :

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

В итоге:

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

When two developers work together design pattern quality improves-> эта фраза не имеет смысла вообще. По крайней мере, не больше смысла, чем When two bakers work together wheat quality improvesили When two race drivers work together asphalt quality improves.
Френель

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

2

Есть несколько преимуществ для парного программирования:

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

В википедии также есть хорошая сводка затрат и выгод в вики .

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.