Мы с Тамарой кодим парой: что такое парное программирование
2026-02-21 07:52 Diff
https://skillbox.ru/media/code/my-s-tamaroy-kodim-paroy-chto-takoe-parnoe-programmirovanie/

#статьи

  • 27 окт 2023
  • 0

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

Писать код в четыре руки на одной клавиатуре — что может быть веселее?

Иллюстрация: Оля Ежак для Skillbox Media

Востоковед, интересующийся IT. В прошлом редактор раздела «Системный блок» журнала «Fакел», автор журналов Computer Gaming World RE, Upgrade Special, руководитель веб-ресурсов компании 1С-Softclub.

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

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

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

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

Кадр: фильм «Социальная сеть» / Columbia Pictures

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

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

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

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

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

Кадр: сериал «Отмена действия» / Netflix

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

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

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

Рон Джеффрис,
Strengthening the Case for Pair-Programming

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

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

«Зонневельд сидел за столом напротив [Дейкстры], и каждая инструкция в компиляторе записывалась (ими обоими) только после того, как они обсудили и договорились, что она верна. Вечером каждый из них забирал собственную копию кода домой на случай пожара».

Сэр Тони Хоар, британский информатик.
What can we learn from Edsger W. Dijkstra?

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

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

Кент Бек
Фото: Kent Beck / Medium.com

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

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

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

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

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

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

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

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

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

Алистер Кокберн, Лори Уильямс,
The Costs and Benefits of Pair Programming

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

«Меня успокаивает, что партнёр постоянно проверяет мой код. Я могу быть уверен, что сделал хорошую работу, если кто-то другой, кому я доверяю, наблюдал за ней и одобрил».

Алистер Кокберн, Лори Уильямс, 
The Costs and Benefits of Pair Programming

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

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

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

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

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

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

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

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

Некоторые из первых парных сессий прошли гладко. Другие занятия проходили неловко. Общение было последовательным и скупым… Примерно через неделю я заметил удивительное явление. Разработчики стали разговаривать друг с другом. Как люди. И смеялись. Они действительно начали получать удовольствие и доверять друг другу. За несколько недель они стали настоящей командой».

Из материалов интервью А. Кокберна

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

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

Чак Эллисон, редактор-консультант, C/C++ Users Journal.
Strengthening the Case for Pair Programming

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу