Парное программирование, когда водитель и наблюдатель имеют разный уровень квалификации и опыта


30

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

Но мне просто интересно, стратегия еще работает в этом случае. Например

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

Не могли бы вы предложить стратегию парного программирования в приведенном выше случае?


13
Убедитесь, что оба согласны с тем, кто имеет более высокий уровень квалификации и должен тренировать другого. Если эти роли / уровни навыков не ясны, парное программирование, вероятно, не будет работать и приведет к конфликту.
Джорджио

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

Ответы:


27

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

На C2 wiki есть интересное резюме о передаче знаний с использованием парного программирования . Более старший человек, которого привлекли к работе в качестве наставника команды, многому научился у младших программистов, и его знания даже выросли в результате сотрудничества с более младшими, менее опытными разработчиками программного обеспечения. Есть и другие истории о том, что опытные программисты были в паре с экспертами по предметной области.


Согласовано. У меня есть младший в команде, и парное программирование резко повысило качество его кода. Тем не менее, парный просмотр его кода также был очень полезен.
Sulthan

2
Вы просто должны быть осторожны, чтобы старший человек не был водителем в 100% случаев.
HLGEM

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

1
Я согласен с @ThomasOwens; наличие менее опытного партнера приводит к тому, что его / ее опыт приобретается быстрее, чем любой другой метод, и в то же время позволяет им делиться своими идеями и идеями с более старшим партнером. Это не займет много времени, прежде чем их уровень мастерства станет намного ближе.
Эрик Кинг,

1
Интересно, делает ли это старшего разработчика более обязанным практиковать то, что они проповедуют?
JeffO

16

Это именно то, для чего было разработано парное программирование: обмен опытом между старой бородой и молодым кузнечиком.

Это двусторонний обмен: ловкие насекомые могут многому научить ревматический мозг.


1
Хотя вы, вероятно, считаете меня одним из них, я бы послушал «ревматические мозги» ...
Марьян Венема

1
Я не думаю, что термин «пользовательская история» может быть применен здесь. Пользовательские истории описывают бизнес-требования к программному обеспечению.
Конрад Рудольф

Да, я думаю, что он имеет в виду «вариант использования».
Йорг Миттаг

Понижено: ни слова о стратегии, как справиться с упомянутыми случаями.
try-catch-finally

10

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

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

Разрыв в опыте между ними является ключом к парному программированию imho.


2
Согласовано. Я мог представить себе парное программирование с собой, и я думаю, что это было бы совершенно бессмысленно. Разрыв - это то, что создает различные перспективы, связанные с тем, чтобы 4 глаза покрывали больше возможностей в вин-диаграмме возможностей. Два человека с одинаковыми навыками и опытом увидят то же самое, что и другие, и не получат никакой выгоды.
Джимми Хоффа

5

Я опишу свой опыт и постараюсь извлечь из него «стратегию».

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

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

Еще одним преимуществом является легкость сосредоточиться на задаче, не отвлекаясь (ха-ха, представьте, что вы открываете Twitter перед носом вашего босса).

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

Таким образом, это на самом деле не парное программирование, так как он практически не мог просмотреть код в том виде, в котором он был напечатан. Однако, это казалось разумной стратегией (по крайней мере, какое-то время). В конечном итоге это сработало из-за относительной простоты как методологии разработки (я имею в виду, что не было задействовано никаких сложных методик проектирования программного обеспечения, таких как шаблоны ООП), так и предмета. Я думаю, это не сработало бы, если бы нам пришлось разрабатывать компилятор. Я полагаю, что это все еще могло бы работать, если наблюдатель, не являющийся программистом, участвует в процессе разработки небольших четко определенных частей. Скажем, нормально, чтобы он наблюдал за программированием функции «вычислить параметр X из Y и Z по заданному алгоритму», но может быть не так хорошо, чтобы он наблюдал за всем процессом проектирования системы (то есть за развитием архитектуры программного обеспечения, то есть за иерархией классы,

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

Надеюсь, это поможет :)


Это хорошее опытное объяснение!
Сакарес

2

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

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


Разработчики с низким уровнем квалификации реже копируют и вставляют при программировании сами? Обычно это происходит, когда никто не смотрит.
JeffO

1

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

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

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