Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>27 окт 2023</li>

3 <li>0</li>

4 </ul><h2>Мы с Тамарой кодим парой: что такое парное программирование</h2>

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

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

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

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

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

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

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

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

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

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

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

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

17 Кадр: сериал "Отмена действия" / NetflixПри этом "ведущий - штурман" - это лишь один из подходов к парному программированию. Он лучше всего работает, когда оба участника примерно равны по уровню. Если это не так, можно использовать и другие способы:

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

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

20 Рон Джеффрис,<a>Strengthening the Case for Pair-Programming</a>

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

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

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

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

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

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

27 Кент БекФото: Kent Beck / Medium.comКент Бек стал известен в комьюнити, когда в 1996 году перезапустил систему расчёта зарплаты в компании Chrysler, которая была настолько неудачной, что не справлялась со своей главной задачей - она неверно считала месячную зарплату. С помощью экстремальных техник программирования, включая парное, Бек успешно реанимировал проект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

49 Из материалов<a>интервью</a>А. Кокберна

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

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

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

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

54 <ul><li>Ниже вероятность, что кто-то будет вас отвлекать: коллега, увидев двух программистов, которые что-то обсуждают друг с другом, скорее пройдёт мимо.</li>

55 <li>Легче восстановить контекст: если один отвлёкся, напарник вернёт его в состояние потока.</li>

56 <li>Можно больше сделать, поскольку меньше отвлекаешься: не будете же вы смотреть тиктоки, когда коллега заглядывает через плечо. Если, конечно, вы оба ответственно подходите к работе.</li>

57 <li>Меньше нагрузка на руки и кисти, так как они периодически отдыхают. Тут мы, конечно, утрируем, ведь работа программиста - это не только писать код :)</li>

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

59 <ul><li>Оно может стать пустой тратой ресурсов, если задача слишком простая и не требует глубоких знаний или принятия сложных решений.</li>

60 <li>Оно может стать проблемой, если у участников есть проблемы с общением или они не переносят друг друга. А ещё - если они неспособны сосредоточиться, когда кто-то рядом.</li>

61 <li>Парный подход требует от участников полной вовлечённости и ответственного отношения к работе.</li>

62 <li>При переключении ролей нередко случается "потеря темпа".</li>

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

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

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

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

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

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

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

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

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

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

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

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

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

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