Мы с Тамарой кодим парой: что такое парное программирование

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

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

Одна голова хорошо, а две — лучше

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

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

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

Ведущий и штурман: роли участников

В парном программировании у каждой роли есть название:

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

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

Как мы отметили выше, через какое-то время участники меняются ролями. Напарники тоже могут меняться, то есть следующее задание вы можете делать уже с другим человеком.

При этом «ведущий — штурман» — это лишь один из подходов к парному программированию. Он лучше всего работает, когда оба участника примерно равны по уровню. Если это не так, можно использовать и другие способы:

«Штурман на заднем сиденье» — если штурман более опытен, чем ведущий, он берёт на себя принятие уже не только стратегических, но и тактических решений и как бы обучает начинающего. Если же наоборот, то ведущий параллельно с написанием кода может продумывать стратегию и обучать штурмана. Хотя бывают и исключения — джун тоже многому может научить.

«Пинг-понг» — этот подход тесно связан с разработкой через тестирование (test driven development). В этом случае один пишет сначала тест, а второй — код, который должен пройти этот тест, затем роли меняются. Этот подход также лучше всего работает, когда разработчики находятся на одном уровне.

Читайте также:

JUnit: модульное тестирование в Java и test-driven development

Дейкстра и экстремалы: немного истории

Одним из первых, кто применил парный подход к программированию, был знаменитый нидерландский учёный и программист Эдсгер Дейкстра. Это случилось, когда он вместе со своим коллегой Яапом Зонневельдом писал компилятор для Algol 60.

Читайте также:

Человек-алгоритм: жизнь и въедливые наблюдения Эдсгера Дейкстры

Однако как полноценная практика ПП появляется позже. Оно возникло в рамках новой методологии — экстремального программирования (extreme programming, XP), которую в конце 1980-х придумал разработчик Кент Бек.

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

Кент Бек стал известен в комьюнити, когда в 1996 году перезапустил систему расчёта зарплаты в компании Chrysler, которая была настолько неудачной, что не справлялась со своей главной задачей — она неверно считала месячную зарплату. С помощью экстремальных техник программирования, включая парное, Бек успешно реанимировал проект.

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

Зачем нужно парное программирование

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

Так, в одной работе на тему ПП описан эксперимент, в котором участвовали 15 программистов: пять пар и пять одиночек. В течение 45 минут они решали сложную задачу — писали сценарий проверки согласованности базы данных. В итоге пары справились с задачей на 12 минут быстрее и представили, по всем тестам, более читаемый и работоспособный код.

Кроме того, программистам понравилось писать код в тандеме, хотя изначально они относились к этой затее скептически.

Давайте выделим и другие преимущества парного программирования.

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

Удовлетворённость. Люди, работающие в паре, считают, что получают больше удовольствия, чем те, кто работает в одиночку.

В ходе онлайн-опроса профессиональных программистов, работавших в паре, 96% заявили, что получают больше удовольствия от такой работы, чем когда программируют в одиночку. Кроме того, практически все опрошенные заявили, что парная работа даёт им больше уверенности в своих решениях.

Количество кода. Эксперимент, проведённый в Университете Юты показал, что у программистов, работавших в парах, были не только более качественные программы, но и меньше строк кода, чем у одиночек.

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

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

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

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

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

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

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

Помимо этого, установлено, что во время парной работы:

• Ниже вероятность, что кто-то будет вас отвлекать: коллега, увидев двух программистов, которые что-то обсуждают друг с другом, скорее пройдёт мимо.
• Легче восстановить контекст: если один отвлёкся, напарник вернёт его в состояние потока.
• Можно больше сделать, поскольку меньше отвлекаешься: не будете же вы смотреть тиктоки, когда коллега заглядывает через плечо. Если, конечно, вы оба ответственно подходите к работе.
• Меньше нагрузка на руки и кисти, так как они периодически отдыхают. Тут мы, конечно, утрируем, ведь работа программиста — это не только писать код :)

Сложности и недостатки

Вопрос: если парное программирование так замечательно, почему оно до сих пор не стало мейнстримным течением в разработке? Оказывается, как и у любой техники, у ПП есть свои ограничения:

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

Если обобщить, парное программирование требует от участников развитых мягких, или гибких, навыков (недаром работа в парах — это одно из воплощений Agile-разработки). Это и уважительность, и открытость, и умение слушать, и умение понятно формулировать свои мысли, и много что ещё.

Читайте также:

«Главный скилл — это уважение»: Евгений Антонов о самых важных soft skills в IT

Советы молодым парам

Если вы надумаете попробовать писать код в паре, вот несколько рекомендаций.

Начните с чёткой постановки задачи. Вы должны на берегу знать, чего хотите добиться. Идеально, если у вас уже есть какой-то план — чем меньше в задаче неизвестного, тем проще над ней работать. Не стоит сразу браться за большие задачи: чтобы выдерживать длинные сессии парной работы, нужен опыт.

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

Не диктуйте код. Ведущий тоже должен думать о том, как решить текущую задачу, а не просто пассивно набирать текст.

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

Синхронизируйтесь. Бывает так, что в процессе работы напарники теряют общий контекст — например, один закапывается в детали реализации, а другой — в нюансы архитектуры. Это нормально. Если это случится, обсудите с напарником все неясности, найдите общий язык и синхронизируйтесь снова.

Часто меняйтесь ролями — хотя бы каждые полчаса. Это позволит вам сохранить вовлечённость и смотреть на работу под разными углами. Кроме того, трудно удерживать внимание на чём-то одном дольше получаса. Смена ролей подзарядит вас.

Зачем себя ограничивать: кодим всей командой

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

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

Главное преимущество моб-программирования в том, что тут вместо одной или двух голов — сразу несколько. Можно использовать силу коллективного разума на полную мощность.

Что в итоге

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

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