Как организовать работу программистов с максимальной эффективностью? Одни из способов — парное программирование (pair programming), вариант методики гибкого программирования (agile programming). У такого подхода есть ряд преимуществ и недостатков. Поэтому интерес представляет практический опыт, которым с InformationWeek поделился разработчик Фил Горовиц из компании Perforce Software.

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

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

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

Ему довелось воспользоваться этим методом в ходе одного проекта, для которого потребовался опыт разработки облачного ПО, отсутствующий у сотрудников Perforce Software. Консультанты из Pivotal Labs предложили парное программирование. Была собрана команда, включающая по четыре сотрудника из каждой компании, причем состав пар менялся каждый день, чтобы люди могли получать разные навыки.

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

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

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

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

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

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

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

Горовиц рекомендует ИТ-директорам и руководителям отделов разработки не применять к парному программированию подход «все или ничего», а использовать его, если нужно расширить набор навыков программирования и знаний у своей команды. К тому же применение такого подхода может дать программистам толчок к переходу от индивидуального стиля работы к более открытому и коллективному. А чем шире в команде развито сотрудничество, тем успешнее результаты.