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


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.