Парное программирование на собеседованиях

Также это даст интервьюеру возможность предложить вам больше информации и сразу начать сотрудничать с вами. Однако оказалось, что привыкнуть к такому стилю работы нелегко. Например, Горовицу для этого потребовалась неделя, причем самым тяжелым был первый день, после которого он с трудом нашел силы пойти домой. Потом стало полегче, но все равно участники проекта чувствовали сильное переутомление из-за напряженной работы. Было трудно успевать за коллегой, который сидит рядом, программирует и одновременно объясняет новые концепции, связанные с языком, процессами и инструментами.

• Поэтому возьмем определение Кента Бека из книги «Экстремальное программирование».
• Результаты исследований соответствуют и моим наблюдениям.
• Когда перед вами стоит сложная задача, вроде решения логической головоломки или создания новой фичи, есть соблазн сразу взяться за самый сложный сценарий.
• Рассмотрим оптимальные модели поведения в зависимости от типа недостающих знаний и конфигурации пары.
• Недостаточно просто найти напарника для новых сотрудников, чтобы они “магическим образом” вошли в курс дела.

В компании Menlo 80% программистов называют себя интровертами, тем не менее, им нравится работать в паре. Потому что интровертам нравится работать сообща с людьми, похожими на них самих. Правильное решение — поставить «башню знаний» в пару с другим программистом. Если пара программистов сумеет сработаться, то им будет гораздо легче общаться. При увеличении объема и частоты коммуникаций увеличивается и общий поток информации, циркулирующий внутри команды.

А не лучше ли вдвоём сразу писать код?

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

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

С научной точки зрения

Всегда найдутся люди, которые захотят обладать монополией на знания. Тем не менее, у парного программирования есть свои недостатки. Не так давно я занимался разработкой ПО в Menlo Innovations — в этой компании не принято самому писать код. Если бы я не попробовал парное программирование, скорее всего, я согласился бы с этими высказываниями.

Именно поэтому в Menlo принято устраивать перерывы в течение дня. Утром сотрудники Menlo собираются на планерку, во время которой они обсуждают, над чем они сегодня работают. Я все еще считаю, что объединение «башни» в пару — это лучшее решение.

Стили парного программирования

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

Была собрана команда, включающая по четыре сотрудника из каждой компании, причем состав пар менялся каждый день, чтобы люди могли получать разные навыки. Главный аргумент против заключается в повышении расходов. Зачем платить двум программистам за то, что может сделать один? По мнению Горовица, возможность повысить квалификацию, овладеть новыми навыками и является главным преимуществом парного программирования. Код становится примером, а вопросы раскрывают суть действий. Строгое парное программирование – более строгая версия стиля Штурман/Водитель, в которой «Штурман» говорит «Водителю» что делать, а «Водитель» только пишет то, что ему говорят.

Высокомерное программирование

Таким образом новичок может видеть и слышать своего учителя и получать от него непосредственные инструкции. Было время, когда мы чувствовали, что уже готовы уже все бросить, все, кроме работы “в связке”. Когда я был ведущим, я старался описать проблему таким образом, чтобы мой партнер мог как можно лучше вникнуть в ее суть. Затем в бой вступал он и боролся, до тех пор, пока не доходил до парное программирование мертвой точки… затем у меня появлялась какая-нибудь хорошая идея… и так далее. Наверное, многие назовут этот метод “мозговым штурмом”, но у меня остается после него совсем другое ощущение. И наконец, еще одним преимуществом постоянных проверок кода является то, что с их помощью разработчики узнают новые способы и стили кодирования, особенности языка и лучше представляют себе всю систему.

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

Парное программирование: эффективная или сомнительная методика?

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

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