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

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

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

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

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

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

Измерять эффективность на уровне проекта бесполезно, если вы потеряли некоторых из своих разработчиков - или уволили их - по ходу дела.

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

По моему опыту, парное программирование не учитывает три конкретных фактора: преобладание интровертов (примерно 33% сотрудников), потребность в «глубокой работе». (без чего некоторые классы проектов никогда бы не были реализованы) и поощрение разнообразия подходов / идей.

Давайте посмотрим на них немного подробнее ...

ИНТРОВЕРТЫ: МЫ ВЕЗДЕ!

Смейтесь, если хотите, называйте это слишком «болезненной» проблемой, если нужно, но интроверты повсюду.

Если верить исследованиям, мы составляем примерно 33% населения, и… из нас получаются действительно отличные инженеры и руководители программного обеспечения.

(Если вы не знакомы с этой темой, я настоятельно рекомендую книгу Сьюзен Кейн Тихо: сила интровертов в мире, который не может перестать говорить)

Интроверты и экстраверты часто привносят в проект разные сильные стороны, поэтому полное использование группы разработчиков - это то, что мы, очевидно, хотим делать, если мы смотрим на производительность и эффективность - требует, чтобы мы играли для обоих типов личности.

Природа создает разнообразие в популяциях именно потому, что это сила. Мы должны это использовать.

Мы по-разному относимся к человеческому взаимодействию: интроверты процветают в более спокойной и вдумчивой обстановке, которая прерывается взаимодействием. Экстраверты преуспевают в человеческом общении. Никто не является на 100% тем или иным; даже истинным интровертам нравятся периоды взаимодействия, и люди в одной группе могут действовать (в течение коротких периодов времени), как их коллеги, хотя это истощает их гораздо быстрее, и они не могут делать это слишком долго.

Непрерывная работа с другим разработчиком просто не работает для интровертов. Слишком много «личного времени» истощает нас быстрее, чем экстраверты. Держу пари, ты не получишь от нас 8 часов; больше похоже на 2, а потом мы как зомби. Я определенно не мог программировать вместе с кем-то еще больше часа или около того в день.

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

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

ГЛУБОКАЯ РАБОТА: ПОЧЕМУ ЭТО ВАЖНО

Большая часть работы, которую мы выполняем как разработчики, - это глубокая работа (см. Книгу Кэла Ньюпорта по этой теме). Вам нужно уединение на продолжительный период времени, чтобы уйти достаточно глубоко, чтобы иметь определенные озарения; даже видеть и работать с определенными классами решений.

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

Если использовать аналогию с дайвингом: вы всегда всплываете на поверхность, чтобы взаимодействовать, затем снова пытаетесь погрузиться в глубину… вы тратите большую часть своего времени на всплытие и возвращение.

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

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

Глубокая работа - это не просто чрезмерно сложная или избыточная работа: для многих классов проектов она необходима.

Простота - это сложно. «Очевидное» иногда может потребовать серьезного глубокого размышления, прежде чем оно станет таковым.

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

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

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

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

РАЗНООБРАЗИЕ ПОДХОДОВ

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

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

АЛЬТЕРНАТИВЫ ПАРНОМУ ПРОГРАММИРОВАНИЮ

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

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

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

Я бы сказал, что наличие партнера по кодированию для задачи по-прежнему может быть хорошей идеей, но, возможно, контракт может быть другим: Может быть, они сядут с вами для просмотра кода в определенных ключевых точках задачи. , с чем вы оба согласны с самого начала. Например, когда вы написали тесты, определяющие вариант использования (если вы хорошо выполняете TDD), то когда вы предложили скелетную схему для решения основная проблема, то по мере того как вы доделываете каждый ее кусочек, а потом в конце. Кроме того, если вы застряли и цените взаимодействие… тогда приведите их к вам.

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

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

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