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

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

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

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

Вот так!

Обмен контекстом

Это самое важное, поэтому оно первое в моем списке… Каков «автобусный фактор» команды, в которой вы сейчас работаете? Могу поспорить, что вы могли бы подумать об одном человеке в вашей команде, который, если бы он попал под автобус (очень печально), то проект действительно пострадал бы. Следовательно, «коэффициент автобуса» вашего проекта равен «единице», и компания, в которой вы работаете, должна относиться к этому как к чрезвычайной ситуации. Но держу пари, что нет.

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

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

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

Обмен навыками

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

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

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

Кроличья нора

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

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

Избегайте кроличьей норы кодирования с командой парного программирования!

Поделились проблемой

Когда что-то идет не так, как здорово иметь плечо, в которое можно поплакать!

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

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

Нет «я» в команде.

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

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

Общий контекст, общие навыки, общие проблемы и общие успехи!

Код лучше

Наблюдение двух пар глаз за кодом во время его написания почти по определению приведет к улучшению кодовой базы. Только дополнительная широта опыта поможет. Однако действительно большое преимущество заключается в необходимости объяснять и обосновывать свои решения по мере их принятия. Попытка объяснить решение во время проверки кода через 3 дня и 3000 строк кода позже невозможна. Наличие кого-то под рукой для критики также предотвращает нагромождение кода поверх шаткого фундамента.

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

Качество кодовой базы определяет долгосрочный успех проекта. Используйте сопряжение для повышения качества кода.

Окончание работы вечером

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

На самом деле это не вариант, если только ваша пара на день не захочет нырнуть в вашу яму YouTube (маловероятно).

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

Нет необходимости делать код-ревью

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

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

Если была допущена какая-то фундаментальная ошибка, исправлять ее при проверке слишком поздно — ошибка должна быть устранена по мере ее совершения, и не разрешается писать какой-либо дополнительный код поверх нее.

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

Это быстрее

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

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

это веселее

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

Гораздо веселее решать проблемы и находить инновационные решения в паре.

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

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

Работа тоже должна приносить удовольствие!

Вывод

Парное программирование сделает вашу жизнь лучше. Давай!

Существует множество преимуществ для отдельных членов команды, команды в целом, проекта и компании. Итак, еще раз скажу…