Как вы можете достичь и поддерживать поток при парном программировании?


17

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

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

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

Как вы можете достичь и поддерживать поток при парном программировании?


4
Я не согласен, что другие пары могут просто прервать в любое время.
JeffO

3
Альтернативой Flow является идентификация и поддержание позиции на пике Ballmer . Для этого может потребоваться много экспериментов, времени и скотча.
Полное судно на воздушной подушке

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

Ответы:


15

Редактировать: Отказ от ответственности - Вот как я определяю «зону»: A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

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

В « Чистом кодере » есть прекрасная глава, в которой дядя Боб убедительно объясняет, почему «попасть в зону» - обманчиво плохая идея.

Вот, возможно, лучшая альтернатива, чем «попасть в зону»: подумайте прямо и подумайте спокойно и профессионально, что вы делаете. Связь. Поделитесь мыслями с вашим партнером (ами). Определите реальные проблемы. Обсудить возможные решения. Вы можете не чувствовать себя сверхъестественно сфокусированным, но вы, вероятно, будете принимать правильные решения и доступные проекты.

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

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

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


2
Я бы проголосовал миллион раз, если бы мог, профессионалы учатся работать, находятся ли они «в зоне» или нет. Профессионалы могут работать с людьми, мешающими им задавать вопросы, с шумом вокруг них, и вместе с другими людьми, фактически ведущими беседы о том, как выполнять любую задачу, над которой они работают вместе. Я не заинтересован в работе с примадоннами, у которых должны быть особые условия для работы.
HLGEM

7
@HLGEM - Я не думаю, что иметь доступ к тихому месту для работы, когда это необходимо, слишком много, чтобы просить.
JeffO

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

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

2
@Yam Marcovic: Это не та производительность, о которой я думал (создавая больше кода более низкого качества): если кто-то использует изоляцию в качестве предлога для выполнения того, что он хочет, он не будет более продуктивным. Для меня поток означает не возиться и писать много кода, а скорее систематически работать над конкретной задачей, не прерываясь другими, не связанными с ней задачами.
Джорджио

5

Парное программирование иногда требует периодов изоляции от вашего партнера.

пример

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


Почему реализация не должна выполняться в парном программировании?
попробуй поймай наконец

5

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

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

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

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


1
Смысл парного программирования не мешает друг другу расслабиться; это даже не будет эффективным. Дело в том, чтобы иметь обзор кода в режиме реального времени.
Лев

3
@Lev: проверка кода перед фиксацией гораздо эффективнее: проверка занимает от нескольких минут до получаса, а не весь рабочий день.
Джорджио

@ Джорджио Не совсем. Например, может случиться так, что вы сделаете ошибку, а затем тратите время на ее обнаружение, и только потом ваш код проверяется и фиксируется. Если бы вы запрограммировали пару, ваш партнер заметил бы ошибку и сэкономил время отладки.
Лев

1
@Lev: «Если бы вы запрограммировали пару, ваш партнер заметил бы ошибку и сэкономил бы время отладки.»: Нет никакой гарантии, что ошибка обнаружена либо при парном программировании, либо при проверке кода. Например, после шести часов парного программирования человек может быть настолько уставшим, что легко не замечает ошибок.
Джорджио

Очевидно, что нет никаких гарантий, но это может помочь.
Лев

3

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

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


0

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

  • Дизайн кода

  • Typing

  • Изучение новых вещей о домене и коде

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

Когда я продуктивно занимаюсь парным программированием, я получаю чередующиеся периоды набора текста, за которыми следуют периоды мышления и размышления. Это где много скрытых вещей проявляют себя, и может появиться другой дизайн. Если я иду в кроличью нору, мой партнер по паре может вытащить меня из нее. Разговор / объяснение чего-то настоящему человеку имеет такой замечательный эффект, как-то проясняя ваши мысли. Иногда я скучаю по тому, чтобы быть в «потоке», но я думаю, что гораздо больше помогаю своей команде, когда я занимаюсь парой, чем когда я программирую соло. После всего программирования! = Печатать. Программирование происходит в мозгу, и лучшее программирование происходит, когда два мозга сотрудничают и критикуют друг друга.

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