Несколько недоразумений парного программирования

Автор оригинала: RayooTech
  • Перевод
У меня достаточно много опыта в программировании, накопленного за последние несколько лет. Часть опыта я приобрёл работая в своей команде, что-то при работе с клиентам, а некоторый опыт появился благодаря coding dojo и работе на open source проектах.
Для программистов знающих как использовать парное программирование оно предоставляет возможность улучшить свою производительность. Но при этом не стоит ожидать, что программисты значительно улучшат свою производительность с самого начала работы. Парное программирование требует постоянного обучения, а также осознания самими программистами чёткой разницы между исполнителем (тот кто стучит по клавиатуре), и штурманом. Ниже приведено более детальное описание.

1. Недоразумения о штурмане.


A. Это тот, кто постоянно приказывает.
Те, кто любят отдавать приказы, обычно просят исполнителя добавить в конце скобочку «)», а после него многоточие «…». При этом они не заботятся об общей картине в целом, а больше обеспокоены конкретными деталями в программировании. На самом деле, подобный человек скорее сам хочет побыстрее оказаться за клавиатурой. Поэтому когда вы сталкиваетесь с тем, кто любит покомандовать, просто предложите ему своё место за клавиатурой.
B. Это тот, кто любит исправлять ошибки в правописании.
Если штурман постоянно сидит возле вас, исправляя каждую вашу ошибку, то у него просто не будет времени для реального управления. Поэтому когда он вновь начнёт исправлять ваши ошибки, просто начните с ним разговаривать или предложите ему принести вам чашечку кофе (ну или ещё что-нибудь).
C. Это тот, кто критикует.
Критик будет критиковать каждую написанную вами строчку кода. Если он действительно окажется прав, то в будущем он не будет его использовать, и настойчиво требовать своего. Постарайтесь поменяться своими ролями, и тогда критик останется полностью удовлетворенным вашим кодом.
D. Это тот, кто тихо себя ведёт.
Тихий человек – это некто, кто лишь выражает своё мнение. Он просто смотрит на вашу работу. Попытайтесь узнать его мнение о том, что вы программируете, или узнать, какой следующий тест вам необходимо написать.
E. Это тот, у кого нет мышления.
Это тип людей, которые служат лишь для того, чтобы постоянно отвлекать вас, а не предлагать вам какие либо конструктивные мнения и решения проблем. Поэтому просто позвольте ему уйти. Вы вполне способны и самостоятельно заниматься программированием, чем делать это с человеком, который вам постоянно мешает.

2. Недоразумения об исполнителе.


A. Это тот, кто не говорит, что он делает.
Это тип людей, которые просто пишут код, никому не говоря о том, что они пишут. Штурман должен выяснить, для чего необходим этот код. При этом между исполнителем и штурманом не бывает обсуждений о выбранных методах и способах их реализации. Штурман просто должен выслушать мнения и узнать о планах исполнителя.
B. Это тот, у кого сложилось большое самомнение.
Подобные люди обычно игнорируют предложения штурмана, поскольку считают свои идеи гораздо лучшими. Столкнувшись с подобным, лучше просто остановиться и начать заниматься следующей задачей. Тот, у кого собственная самооценка слишком завышена, вряд ли сможет быть хорошим штурманом. Вполне вероятно, что он скорее всего сможет лишь отдавать приказы либо критиковать.
C. Это тот, кто не знает что и как сделать.
Такие люди обычно мало получают удовольствия от парного программирования. Они возбуждены, и просто не в состоянии справляться с текущей ситуацией. Просто убедитесь, что на самом деле вы исполнили роль штурмана наилучшим образом. Необходимо быть крайне осторожным, высказывая свои мнения, ну и в первую очередь предложить свою поддержку. Большинство программистов испытывают подобное в самом начале. Поэтому не стоит возлагать больших надежд. Вначале позвольте ему побыть штурманом, либо найдите другого штурмана, способного сработаться с данным исполнителем.
D. Это тот, кто пропускает куски кода.
Такому человеку нравится пропускать часть кода, в результате чего штурман перестает понимать что к чему. В подобной ситуации штурман должен сбавить темп и узнать о дальнейших планах исполнителя, а также убедится что тот знает больше горячих клавиш чем он.
E. Это тот, кто не знаком с инструментарием.
Этот тип людей, которые не пользуются горячими клавишами в среде разработки, потому что не осознают их эффективность. Попытайтесь поменяться своими ролями, и показать ему свои методики работы. Ну или просто дайте ему готовую шпаргалку со всем списком горячих клавиш.
  • +12
  • 3,3k
  • 3
Поделиться публикацией

Комментарии 3

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

    Но думаю, что это может работать только в случае, если уровень в паре примерно одинаковый, и люди «настроены на одну волну» — иначе не вижу, как можно работать в паре.
      +5
      Хорошо вам было в армии…
        +2
        Не жалуюсь :)

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

    Самое читаемое