Парное программирование

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

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

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

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

Совместное владение кодом

Начну с общих рассуждений. Прежде всего, как начинается проект разработки для парного программирования? В рамках модели XP большая часть работы над проектом формулируется с помощью карт CRC (class, responsibility, collaboration — «класс, обязанности и сотрудничество») — листов бумаги, представляющих собой объекты данного проекта.

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

Результатом этапа CRC становится список небольших задач. Разработчики разбиваются на пары, и каждая пара определяет модульный тест для выделенной ей задачи. Следует отметить, что такие тесты создаются до того, как начинается сам процесс кодирования. По словам сторонников XP, такой подход упрощает и ускоряет разработку приложений: тесты при этом пишутся более аккуратно, поскольку они служат для проверки критически важной функциональности, кроме того, улучшается обратная связь, позволяющая точно определить, что именно требуется сделать. Иными словами, отпадает необходимость тратить время на создание огромных тестов для проверки работоспособности проекта в целом.

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

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

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

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

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

Последний шаг — выполнение всех модульных и функциональных тестов. Вполне вероятно, что этот процесс придется повторить несколько раз, пока не удастся достичь корректной работы и взаимодействия всех объектов. Может понадобиться провести несколько CRC-сессий; объекты, не прошедшие функциональное тестирование, должны быть переданы для доработки другой паре программистов.

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

Конечно, метод разработки хорош настолько, насколько хороши приложения, которые он позволяет создавать, а принципы, заложенные в модель парного программирования, столь кардинально отличаются от основ, на которые опираются методы традиционной разработки, что поневоле вызывают серьезные сомнения. С этой точки зрения в 1998 году метод был изучен в университете Темпля, а в 1999 году этим же вопросом занимались в университете штата Юта. В обоих случаях часть студентов, участвовавших в исследовании, работали индивидуально, а часть — в парах.

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

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

Время покажет, оправдает ли себя парное программирование (да и экстремальное программирование в целом). В компаниях, где этот метод уже используется, например в DaimlerChrysler и Ford Motor, пока не спешат делать какие-то выводы. Тем же, кого давно беспокоят болезненные вопросы разработки приложений — организация связи между программистами, излишняя сложность, контроль и управление и, конечно же, качество программного обеспечения, имеет смысл попробовать парное программирование.

Парное программирование