Парное программирование: преимущества и недостатки

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

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

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

[со слов Рона Джеффриза]

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

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

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

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

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

Команда разработчиков учится общению и совместной работе.

Решение проблем

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

[- Дэвид Уагстафф (David Wagstaff), Salt Lake City]

Мы называем описанный Дэвидом Уагстаффом эффект парной эстафетой (pair relaying). Работающие парами программисты часто сообщают о том, что благодаря этому методу могут решать проблемы гораздо быстрее, а также о том, что этот метод отличается от таких процессов как улучшение качества дизайна системы, обнаружение ошибок при наборе или проведение "мозгового штурма". Под словами "Решение проблем" мы понимаем ту ситуацию, когда оба программиста озадачены сбоями в работе программы или же просто не могут решить, как им следует разрабатывать ее дальше.

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

Очень эффективно совмещать технику "мозгового штурма" и парной эстафеты. Один из опытных программистов заметил:

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

Обучение

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

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

Обучение на визуальных примерах и его роль в ученичестве

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

У книги есть подзаголовок - "периферийное участие в работе на серьезном уровне", который подчервкивает три основных аспекта ученичества: новичок участвует в работе мастера активно; новичку поручают серьезную, ответственную работу и, наконец, что новичок работает на периферии, постоянно приближаясь к более высокому уровню профессионализма. Поначалу новичкам поручается простая (и не самая важная) часть работы. С течением времени его работа приобретает все более ответственный характер.

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

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

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

Специалист в пределах слышимости (Expert In Earshot)

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

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