Это продолжение перевода статьи о парном программировании. С третьей частью можно ознакомиться здесь.
Наш опыт ясно показывает, что парное программирование является важной практикой для создания высококачественного, удобного в сопровождении программного обеспечения. Однако мы также не верим, что подходить к этому вопросу нужно догматично и обязательно работая в паре. Это зависит от того, насколько именно парное программирование может быть эффективным для вас, в какой степени и для каких задач. Мы считаем полезным рекомендовать парное программирование для команд в качестве «разумного варианта работы по умолчанию», а затем обсудить, когда можно сделать исключение.
Давайте рассмотрим несколько примеров, когда полезно сбалансировать то, как и когда вы работаете в паре.
Скучные задачи
Некоторые задачи по написанию кода «скучны», например, потому что они связаны с использованием какого-то четко шаблонного подхода — может быть вам и не нужно объединяться для этого? Вся команда уже знает этот тип подхода, или его очень легко понять, поэтому обмен знаниями не так важен? Или проверка кода в реальном времени менее полезна, потому что хорошо зарекомендовавший себя шаблон успешно использовался в прошлом? Так что да, возможно, вам не нужно объединяться.
«Могу ли я действительно сделать это сам?»
Совместная работа имеет множество преимуществ для начинающих программистов, потому что это возможность относительно быстро учиться у более опытного члена команды. Однако junior-программисты также могут испытывать потерю уверенности в своих силах при работе в паре. «Могу ли я действительно сделать это без того, чтобы кто-нибудь заглядывал через плечо?». К тому же они упускают возможность научиться разбираться во всем самостоятельно. Все мы проходим через моменты разочарования и экспериментов с анализом ошибок, которые в конечном итоге делают нас лучшими программистами. Самостоятельное столкновение с проблемой часто является более эффективным обучающим опытом.
Есть несколько способов противостоять этому. Один из них — позволить джунам время от времени работать в одиночку, с наставником, который регулярно проверяет и комментирует код. Другой способ — позволить junior-программистам работать в команде друг с другом. Они могут вместе находить решения и “выкапывать” себя из кроличьей норы быстрее, чем если бы они работали сами по себе. Наконец, если вы более опытный программист в паре, убедитесь, что большую часть времени находитесь на месте “штурмана”. Дайте “водителю” возможность разобраться во всем — иногда нужно немного подождать, пока вы вместе не упретесь в стену, вместо того, чтобы указывать на нее заранее.
Код-ревью VS парное программирование
“Преимущество парного программирования - в его захватывающей непосредственности: невозможно игнорировать рецензента, когда он сидит рядом с тобой”, - Джефф Этвуд.
Многие люди считают процесс ревью кода достаточной причиной для того, чтобы не практиковать парное программирование. Мы не согласны, что ревью кода — хорошая альтернатива объединению в пары.
Во-первых, обычно есть несколько факторов, которые могут привести к небрежному или поверхностному код-ревью. Например, когда программист и рецензент слишком полагаются друг на друга: программист может отложить несколько небольших решений и улучшений, думая, что проблемы будут выявлены в ходе рецензирования. В то время как рецензент полагается на усердие программиста, доверяя его работе и не слишком внимательно всматриваясь в код. Еще одна закономерность — обычно мы неохотно инициируем переработку того, во что команда уже вложила средства.
Во-вторых, ревью кода может нарушить работу команды, ведь для выполнения проверки необходимо переключить кого-то на эту задачу. Таким образом, чем чаще происходит ревью кода, тем более неприятными они будут для проверяющих, а они должны происходить часто, чтобы обеспечить непрерывную интеграцию небольших изменений. Это приводит к увеличению нагрузки и менее эффективным проверкам.
С помощью Continuous Integration/Continuous Delivery (непрерывной интеграции/непрерывной доработки) мы хотим снизить риск, часто внося небольшие изменения. В своем первоначальном определении это означает практику разработки Trunk Based Development (магистральная разработка). При такой разработке отложенные проверки кода еще менее эффективны, потому что изменения в любом случае немедленно попадают в главную ветку. Таким образом, парное программирование и непрерывная интеграция — две практики, которые идут рука об руку.
Подход, который, по нашим наблюдениям, эффективно используется командами, состоит в том, чтобы создавать пары “по умолчанию”, но запросы на изменения и проверку кода применять в исключительных случаях, когда кому-то нужно изменить рабочий код без объединения усилий. Тогда вы должны внимательно следить за тем, чтобы ваши запросы на пулл реквест “не жили” слишком долго и убедиться, что вы по-прежнему практикуете непрерывную интеграцию.
Но действительно, зачем заморачиваться?
Мы много говорили о преимуществах парного программирования, но еще больше о его проблемах. Для правильного создания пар требуется множество различных навыков, и они могут повлиять на другие процессы. Так зачем беспокоиться? Это действительно стоит того?
Чтобы команда чувствовала себя комфортно и добилась успеха в парном программировании, ей придется работать над навыками, полезными для преодоления ее проблем: концентрация и внимание, организация задач, управление временем, коммуникация, предоставление и получение обратной связи, эмпатия, умение принимать помощь - все эти навыки помогают стать эффективнее. Работа в парах дает возможность совершенствовать эти знания вместе.
Еще один показатель, о котором сегодня широко говорят как о факторе успеха - разнообразие. Доказано, что разнообразие точек зрения, полов, опыта и навыков улучшает работу команды, но часто увеличивает трения. Может даже усугубить некоторые проблемы с парным программированием, о которых мы говорили.
Это предубеждение заставляет нас стремиться к простоте, которая помогает нам во многих ситуациях при разработке программного обеспечения. Но мы не думаем, что это поможет нам в случае парного программирования. Работа в паре кажется трудной, но это не обязательно означает, что это плохо для коллектива. И самое главное, она не должна оставаться жесткой.
Парное программирование, экстремальное программирование и гибкая методология разработки программного обеспечения в целом — все это касается принятия изменений. Специалисты по гибкой методологии программного обеспечения признают, что изменения неизбежны, поэтому нужно быть к ним готовыми.
Полагаем, что еще одна вещь, которую мы должны принять и к которой следует подготовиться — это разногласия, потому что они неизбежны на пути становления высокоэффективной и разнообразной командой. Поддерживая разногласия, мы НЕ хотим сказать: «У нас будет много конфликтов, и поэтому мы станем лучше». Имеем в виду, что команды должны вооружиться инструментами, необходимыми для их преодоления, и всегда иметь их в своем “наборе”, а не только, когда уже есть проблемы. Практикуйте обратную связь, улучшайте командную коммуникацию, принимайте меры по созданию психологически безопасной среды.
Мы считаем, что парное программирование часто избегают, потому что оно может вести к разногласиям, но просим вас дать ему шанс. Если вы сознательно относитесь к нему как к навыку, который можно улучшить, и работаете над этим, у вас получится более устойчивая команда.
