что такое парное программирование
Экстремальное программирование: Pair Programming
Парное программирование является одной из практик XP. Эта практика воплощает экстремальную (преувеличенную) идею Code Review. Если ревью позволяет улучшить качество кода, то давайте делать его постоянно, во время рефакторинга и написания нового кода.
Проблема проведения обычного Code Review заключается в том, что программисты дают очень поверхностную обратную связь, когда просто смотрят на ваш код. Но как только они начинаются с ним работать, вот тогда прилетает настоящая обратная связь по всем тонким местам и недочетам.
Как это делать?
При парном программировании два человека сидят плечом к плечу за одним компьютером. Один из них является «водителем», у него в руках клавиатура и мышка. Второй делает постоянный ревью кода первого, чтобы определить тактические и стратегические недостатки в коде, в том числе ошибки в синтаксисе, логике программы, опечатки и реализации, которые не подходят под существующий дизайн системы. После определенного времени программисты меняются ролями, либо меняют пары.
Исследования
Самый большой скепсис вызывает вопрос: Не будет ли разработка идти медленней, когда два программиста занимаются одной задачей?
Исследования показывают, что работа в паре делает либо с такой же скоростью, как и по одиночке, либо немного (15%) медленнее. Зато код получается намного качественней, содержит меньше ошибок (60%) и технических долгов.
Анти-паттерны
Парное программирование может быть гораздо более интересным и увлекательным, чем программирование в одиночку, если делается правильно. И наоборот, может быть ужасным и скучным по сравнению с работой в одиночку, если делается неправильно.
Как исправить?
Если вы заметили пару программистов, которые работают по этим анти-паттернам, то дайте им обратную связь и укажите на ошибку. Практика показывает, что работу в паре довольно просто может наладить сторонний наблюдатель.
Границы применимости
В реальной практике применять парное программирование получается около 20% времени, а не постоянно, как может показаться из-за духа XP. Конечно, этот процент примерный и зависит от проекта, но в целом до 100% не доходит. Все-таки иногда хочется просто откинутся на спинку кресла и помедитировать на код, подумать о прекрасном и родить идею, как бы этот код сделать еще лучше.
Надо понимать, что парное программирование дает выигрыш при марафоне и является почти убийственным, если мы делаем короткие проекты.
Правильно воспринимать парное программирование, как инструмент, а не панацею от всех проблем. Пробуйте эту практику, чтобы понимать в каких ситуациях она полезна, а в каких можно обойтись и без нее.
Одна голова хорошо, а две — лучше, или парное программирование в действии
Драйвер и навигатор в действии (северокорейский вариант методики)
От переводчика: сегодня публикуем для вас статью Эндрю Спрула, специалиста по Data Science. Он рассказывает о преимуществах парной работы программистов над одним и тем же проектом.
Я часто слышу, как люди говорят, что лучше всего они работают в одиночку. Я понимаю, что некоторые идеи и методы, которые подходят для одного человека, не годятся для другого. Но все же мне близка поговорка «Одна голова хорошо, а две — лучше». Под катом два видео, которые показывают, насколько хорошо над одной задачей могут работать два человека. Это просто гармония — и в прямом, и в переносном смысле.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Здесь второе видео (автор запретил встраивание на сторонних ресурсах, но посмотреть обязательно стоит).
Музыка — не единственная сфера, где сотрудничество двух человек может принести пользу общему проекту. Их гораздо больше, о чем рассказывает профессор социологии из Университета Буффало Майкл П. Фаррелл в своей книге Collaborative Circles: Friendship Dynamics and Creative Work. В частности, он считает, что многие великие идеи появлялись у людей, которые работали в парах: это могли быть ученые, художники, писатели.
В живописи это Моне и Ренуар, в писательстве — Толкин и Льюис, в науке — Крик и Уотсон… Перечислять можно долго. Более того, около половины нобелевских лауреатов в категории «Физиология и медицина» — команды из двух человек.
Ну а в наше время отличные результаты дает «парное программирование», которое «Википедия» описывает как agile-методику разработки программного обеспечения, которая заключается в работе двух программистов за одной рабочей станцией. Один из них, драйвер, пишет код, второй, наблюдатель, следит за процессом и читает каждую набранную строку. Программисты часто меняются ролями.
Эта методика не имеет отношения к работе по модели «учитель-ученик», речь идет о совместной работе двух равных специалистов. Один из них может иметь больший опыт, но работают они одинаково, права равны. В целом, идея заключается в том, что два человека находят решение быстрее, чем один.
Изначально паре может быть сложно слаженно работать, да и вообще такой рабочий процесс многим покажется нелепым. Но здесь, как и везде, нужен опыт. С течением времени работа налаживается и процесс идет уже гладко, практически без проблем.
Повторюсь, в парном программировании две роли: драйвер и навигатор. Главная задача первого — следить за деталями кода, реализовывать идеи, превращая их в строки кода. Драйвер и навигатор должны обсуждать идеи и проблемы.
Навигатор уделяет внимание каждой набранной строке, и это внимание не рассеянное, поскольку ему не требуется набирать текст. Главная цель навигатора — доносить четкие идеи драйверу. Навигатор должен давать драйверу инструкции с определенным уровнем абстракции так, чтобы тот был в состоянии реализовывать их максимально эффективно.
Если у драйвера появляется идея, то навигатор и драйвер могут поменяться ролями. Это помогает партнерам работать синхронно. Обмен идеями сродни брейнстормингу, только это более эффективный процесс, плюс уровень ошибок снижается (как показано на диаграмме выше).
Я могу посоветовать специалистам, которые работают в паре, иногда прерываться и задавать друг другу вопросы. Это помогает мыслить в одном направлении, понимать друг друга и работать качественно.
Парное программирование и рабочий процесс
Недавно я узнал от однокурсника, что у Atom есть пакет Teletype, который позволяет разработчикам трудиться вместе в режиме реального времени, предоставляя коллегам доступ к своему рабочему столу. Это даже лучше, чем если просто сидеть вместе за одной рабочей станцией, поскольку позволяет находиться в более комфортных условиях и меньше отвлекаться.
И не забывайте: ролями в течение дня необходимо меняться. При этом вы не можете использовать таймер, поскольку он будет мешать рабочему процессу. Многие считают, что вы должны меняться ролями в пределах интервала в 30 минут. Но здесь все субъективно.
Период адаптации при переходе одиночек в парное программирование подобен поеданию острого перца. В первый раз все не так, вам не нравится. Но чем чаще вы едите перец, тем скорее он вам начинает нравиться.
В заключение сказанному
Как-то я услышал фразу: «Для того, чтобы идея была реализована в цифре, необходимо, чтобы она прошла через руки другого человека. Этот тип программирования заключается в общении и сотрудничестве». Как мне кажется, именно коммуникация и сотрудничество — две составляющие успешной работы.
Сам я более продуктивен, когда работаю в паре с кем-то. Мой опыт музыканта подсказывает, что играть в ансамбле лучше, чем быть сольным исполнителем. Это не потому, что я зависим от другого человека, скорее, моя уверенность в успехе растет, когда я вижу, что общий труд более эффективен. Сейчас из меня лучший навигатор, чем драйвер, но я постепенно совершенствуюсь. Надеюсь, что эта статья поможет вашим будущим проектам.
Время одиночек прошло: что такое парное программирование
Об экспертах:
Парное программирование было придумано еще в конце 1990-х годов. Его сразу же начали применять автомобильные гиганты Ford Motor Company и Daimler Сhrysler AG. Сейчас метод активно используют во многих ИТ-компаниях, как в больших, например, в Facebook, Pivotal Software, Grockit, так и в растущих, в таких как Drizly.
Понять суть парного программирования очень просто — это когда два специалиста работают в паре за одним компьютером. Такой метод работы встречается не только в разработке, но и в любой другой сфере. Его часто называют «работой в четыре руки».
Парное программирование лучше работает, когда оба разработчика сидят за одним компьютером — это дает больше взаимопонимания и драйва. Однако такую работу можно организовать онлайн с помощью специальных плагинов. За счет того, что оба разработчика погружены в одну задачу, они решают ее быстрее.
Писать код в паре не обязательно: главная ценность парного программирования — в идеях и приемах, которых у двух разработчиков больше, чем у одного. Работа в паре помогает им находить наиболее быстрые способы решения, чтобы затем воспроизводить их в коде.
Если задача сложная, парное программирование начинается у доски: программисты генерируют идеи, рисуют схемы и архитектуру кода. Иногда парное программирование и начинается, и заканчивается у доски: идеи придуманы, а внедрять их в код будет один из программистов. Если задача простая — сразу приступают к разработке.
Выбор роли
Каждый программист берет на себя одну из двух ролей: «водителя» или «штурмана». Один пишет код, а второй направляет первого, но не диктует код дословно, а помогает понять, как реализовать конкретный алгоритм в структуре кода.
Во время работы они могут меняться ролями. Например, когда «водитель» не понимает, куда дальше двигаться, на его место садится «штурман». Чаще всего рекомендуют меняться во время проблемных моментов, иногда это происходит через определенные промежутки времени, например, через каждые полчаса или 100 строк кода.
Есть разные точки зрения насчет того, нужно ли вообще меняться ролями. С одной стороны, можно этого не делать, когда один знает используемый язык программирования лучше другого. Или если нужно проанализировать код или прочитать документацию, это лучше всегда делать более опытному программисту. С другой стороны, если программисты хотят обменяться опытом и научиться новым «фишкам», меняться необходимо.
Стили парного программирования
Роли в парном программировании используют по-разному в зависимости от стиля. Чаще всего разработчики меняют их в зависимости от ситуации.
Используют когда нужно просто работать в паре.
Применяют, если нужно во время работы обучать напарника: более опытный «водитель» успевает и писать код, и рассказывать штурману, почему и как он это делает.
Когда штурман не только следит за стратегией, но постоянно вмешивается в код.
Во время него один из партнеров пишет тест, второй пишет код, который сможет пройти этот тест, затем участники меняются местами. Этот стиль быстро помогает понять, хорошо ли работает код, но требует от разработчиков навыков разработки через тестирование.
Парное программирование для разных сценариев
С помощью этой методики можно легко добавлять в программы маленькие функции. Например, поиск информации в базе данных: она хоть и небольшая, но сложная, над ней надо хорошо подумать, поэтому работа в паре будет очень кстати.
При этом у парного программирования есть минус — оно плохо подходит для решения непростых задач, разработки систем со сложной архитектурой, где много точек входа, выхода и интерфейсов.
Большие продукты редко разрабатываются в парах. Обычно над ними работает команда с тимлидом и архитектором: они разбивают проект на множество мелких задач, ставят их программистам, а те уже сами решают работать отдельно или в парах.
Часто парное программирование используют, чтобы обучать или оценивать новичков. Так в команде растят джуниор-программистов и стажируют студентов, только закончивших вуз. Считается, что такая работа «в четыре руки» гораздо эффективнее обычных лекций или семинаров. Еще метод используют в школах программирования.
Эта методика помогает сближать команду. Если периодически менять напарников, то постепенно все программисты небольшой компании научатся работать друг с другом. Или хотя бы поймут, с кем им комфортно работать, а с кем нет.
Бывает и так, что в парном программировании участвуют и другие специалисты. Например, часто это происходит при разработке игр, когда гейм-дизайнер и программист делают уровень игры вместе. Первый объясняет решения, а второй реализует их в коде. Такой способ работы избавляет от необходимости писать технические задания и почти бесконечно исправлять последствия недопониманий.
Адаптация к парному программированию
Если вы хотите внедрить метод в своей компании, вам нужно:
Если вы программист и хотите начать работать в паре, вам нужно:
Парное программирование становится все популярнее. Метод постоянно проверяется на практике, разработчики рассказывают о нем в своих блогах и вдохновляют других, находят недостатки метода и пытаются их исправить.
При работе в паре программистам проще находить и исправлять ошибки, работа и обучение идут эффективнее и быстрее, а дух команды растет. Одновременно с этим парное программирование может мешать очень опытным разработчикам, у которых и так есть идея и структура решения. Им будет проще реализовать код в одиночку, а не тратить время на обсуждение идей.
Метод отлично подходит для обучения детей, но важно ставить в пару детей разного уровня и возраста. Если это будут сверстники с одинаковым уровнем знаний, парное программирование превратится в соперничество. А если уровень и возраст будут немного разными, получится продуктивная работа в команде. Ребенок с более высоким уровнем будет учиться через объяснения, а ребенок с более низким — через тягу за напарником.
Больше информации и новостей о трендах образования в нашем Telegram-канале. Подписывайтесь.
Парное программирование. Быть или не быть?
Привет. Меня зовут Вадим Бараненко. С украинским офисом EPAM я сотрудничаю в роли архитектора решений. И в этом материале я хотел бы поделиться своими взглядами и опытом в такой интересной теме, как парное программирование (далее — ПП).
С ПП я впервые познакомился около 9 лет назад и практиковал этот подход на разных проектах — часть в харьковском офисе EPAM, часть на территории заказчика в Англии. И этот опыт показался мне интересным и полезным.
Первый проект, на котором я столкнулся с ПП, был для одного из крупнейших ритейлеров Англии. Клиент использовал гибкие методологии разработки, экстремальное программирование (ХР), в частности ПП, test-driven development. Во время этой работы я заинтересовался практиками повышения продуктивности. В тоже время у EPAM появился заказчик, который хотел получить команду с такими навыками. Поэтому я согласился собрать и отстроить инженерные практики.
Вскоре появилась потребность в еще одной команде, и я перешел туда — стартовать процессы в роли лида. Позже переехал в Англию и стал работать уже на стороне клиента. Там у нас была настоящая Agile-команда без лидов, хотя все инженеры были очень опытными. Работать рука об руку с людьми из разных стран и с разным культурным опытом было довольно интересным вызововм. В коллективе были инженеры из Нигерии, Индии, Египта, Англии, Украины. Интересности происходили даже на уровне языка.
Теперь мне все чаще встречаются проекты со значительным объемом работ и конкретными бюджетами. В таком формате едва ли можно позволить двум программистам работать над одной задачей. Однако иногда использовать ПП все-таки можно. Так, три года назад проблема на продакшин «упала» поздно вечером. И вместе с лидом проекта мы сели в пару. Код писали по принципу TDD, чтобы быть уверенными, что ничего не сломаем. И в который раз убедились: когда над кодом работает два инженера с разным мышлением, то вероятность ошибки значительно уменьшается. Простой пример: я увидел в коде пять потенциальных дефектов, столько же — мой партнер. Три дефекта совпали, но в общем мы нашли еще больше огрехов, которые могли привести к ошибкам в продакшине.
Почему ПП — не слишком популярная практика
«Продать» заказчику ПП довольно сложно. Большинство не понимает, почему над одной задачей должны работать два инженера. Поверхностные подсчеты показывают, что проект потребует в два раза больше времени и средств. Чтобы согласиться на ПП, клиент должен или с самого начала позитивно относиться к Agile-методологиям, или проходить через трансформацию собственного бизнеса, желая понять и разобраться в этих процессах. Важно, чтобы ИТ-отдел клиента был готов к гибким технологиям, а сам клиент — настроен платить за качество. ПП дает возможность вывести на рынок практически идеальный продукт в спокойные и ожидаемые сроки. Для жестких дедлайнов, наверное, ПП — не лушчая идея.
Но давайте по порядку. Экстремальное программирование (XP) было создано во второй половине 90-х и на тот период выводило изветсные подходы к созданию продуктов на новый уровень. 25 лет назад, во времена расцвета каскадной модели разрабоки, существовали трудности с тем, чтобы интегрировать, тестировать, создать дизайн разных частей продукта и наладить коммуникации между разработчиками. Одной из практик ХР, которая обещала быстрый обмен знаниями о системе, ревъю кода фактически в режиме реального времени и своевренное создание дизайна системы, стало парное программирование. ПП и сегодня дает возможность заниматься кодом вместе и делать существенно меньшие релизы. Это упрощает внесение изменений и улучшает качество продукта.
Как организовать ПП: наша версия
Процесс ПП можно строить по-разному. Существует канонический подход, который рекомендует Кент Бек (один из основателей ХР): пары инженеров сидят за большим столом с одним монитором, одной мышкой и клавиатурой. Однако в ЕРАМ мы несколько модифицировали этот подход.
Пространство
Два программиста сидят за большим столом с одним системны блоком, но двумя мониторами, мышками и клавиатурами. Так, по нашему мнению, работать удобнее.
Стол должен быть прямым. Вначале мы использовали угловые, но практика показала, что это не очень удобно. При таком подходе иногда приходилось передвигать мебель, чтобы сидеть рядом, иметь нормальное пространство для общения. Такие манипуляции — лишнее время и суета.
Командная работа
Чтобы построить процессы, вы должны иметь авторитет. Ведь иногда сложно объяснить заказчику, менеджменту и инженерам важность ПП.
Если клиент и менеджмент этот подход принимают, а сложности остаются только с командой, вам следует уделить время на построение хороших отношений. Культура должна базироваться на взаимопомощи, а не осуждении.
В ПП один (ведущий) пишет код, другой — наблюдает, осмысливает и корректирует процесс, чтобы он отвечал требованиям дизайна. Такое взаимодействие напоминает связку пилота и штурмана в раллийных гонках. Такой подход требует частой смены ролей, чтобы каждый имел возможность и писать, и проверять код, над которым работает напарник.
Еще одна полезная техника — объединение TDD и ПП, когда один пишет тест, а второй — имплементацию. Потом запускаем тест и меняем роли. При таком подходе никто не заскучает.
Также пары должны постоянно меняться. Благодаря этому каждый программист в команде имеет представление о всей системе, а не только об одной ее части. Сперва мы пренебрегали этой рекомендацией. Во время планирования спринта выдавали одну User Story на пару, а в процессе разработки уже не могли ее разделить. Позже, когда одна пара заканчивала работу над User Story, другие обычно еще продолжали работаь над своими. Конечно, их также нельзя было разделить. Уже в Англии я столкнулся с подходом, который, по моему мнению, работает лучше. Нужно, чтобы задачу брал один программист, а второй ему помогал. Во-первых, мы решаем психологический вопрос, когда некоторым инженерам комфортно работать с одними людьми, но крайне некомфортно — с другими. Во-вторых, решаем вопрос логистический, т.к. помощнику не нужно переносить свои вещи на новое место для непродолжительной работы. Поэтому пару следует создавать на один день или задачу.
Инженеры в паре должны смотреть на одну и ту же самую часть кода, общаться между собой голосом. «Штураману» не следует перебирать управление в свои руки. Хорошая практика — обратить внимание на огрехи, рассказать и обсудить, что можно сделать иначе.
Мой опыт доказывает, что в паре можно качественно натренировать Junior’ов. Это несколько не соответствует канонам, т.к. программисты должны быть близки по своему профессиональному уровню. Но, если подходить к процессу разумно, не отбирать у новичка «руль» и общаться, вполне может сработать.
Надеюсь, я смог объяснить, что ПП может быть полезным на проекте. А теперь перейдем к плюсам и минусам этого подхода.
Преимущества ПП
Обмен знаниями. Вы можете оперативно делиться информацией и не зависеть от одного человека. Если кто-то из команды пойдет в отпуск или на больничный, другие все равно будут иметь полную картинку. Этого можно достичь, если регулярно менять пары.
Качество кода повышается. Разные подходы к работе и взгляды на параметры кода могут дать хорошие результаты.
Лучше дизайн на разных уровнях продукта. Если перед тем как писать код, программисты обсуждают его, то качество кода будет выше во всей системе. Конечно, ХР учит нас, что команда меньше времени уделяет дизайну продукта, чтобы сразу сфокусироваться на коде. Знаете, как часто молодые инженеры начинают писать код, едва получив задание? Вот в таких случаях работа в паре помогает больше думать и экономить время на исправление дефектов. На мой взгляд, это даже эффективнее, чем два программиста, которые работают над двумя разными задачами параллельно.
Выше эффективность команды. Как уже отмечал, если кто-то присматривает за работой специалиста, он выполняет ее лучше, чем в одиночку. И это не история о так называемых low-перформерах (т.е. тех, кто демонстрирует посредственные результаты). Это элементарная психология.
Меньше контроля со стороны менеджеров. Ведь в ПП члены команды контролируют друг друга. Общая ответственность за выполнение задания мотивирует показывать более высокие результаты.
Недостатки ПП
Инженерам психологически сложно начать работать с кем-то в паре. Во-первых, не всем нравится, когда за их работой бдительно следят. Так, когда в 2012, будучи Senior-уровня, я начинал работать в паре, то боялся, что могу чего-то не знать, ищу ответы на некоторые вопросы в Сети. Теперь же я — архитектор решений, и практика доказала, что люди не могут знать все и это нормально. Во-вторых, не все стремятся работать 100% рабочего времени. Хороший результат — шесть продуктивных часов. Больше — и команда может дойти до выгорания, исчерпать свои ресурсы. Чтобы избежать этого можно внедрить в парах известный метод Pomodoro: так инженеры будут работать 20-30 минут вместе, а потом уходить на 10-минутный перерыв, чтобы переключиться.
Не каждому заказчику можно легко доказать важность ПП. Самое сложное — доказать эффективность такого подхода клиентам, далеким от ИТ-сферы (ведь зачем двоим работать над тем, что может сделать один?). А самое простое — клиентам, проекты которых имеют фиксированные дедлайны и объемы работы на конкретный период. Такие проекты идут вразрез с некоторыми принципами гибких методологий, ведь команда только частично контролирует процесс, однако ПП позвояет эффективнее решать сложные задачи.
Когда с процессами что-то пошло не так. Например, лид, Scrum-мастер или другой ответственный человек пропустил кризисную ситуацию. Скажем, или никто сразу не установил правила работы в парах, или посадил за один стол совсем разных по темпераменту или профессиональному уровню специалистов, или вовсе забыл о необходимости смены пар. Все это ломает подход к ПП, плохая репутация проекта распространяется со скоростью света, и привлекать новых инженеров становится все сложнее. Самые большие трудности возникают, когда люди не взаимодействуют эффективно, не доверяют друг другу и не понимают, зачем им работать вместе.
Работать удаленно и применять ПП практически нереально. Есть некоторые онлайн-инструменты, но я практически никогда ими не пользовался. Здесь не хватает главного — живого контакта людей.
И минутка стереотипов Бытует мнение, что программисты не очень людям иметь дело с другими людьми. Мол, им больше по душе общаться с «железками», а в ПП придется активно взаимодействовать с другими членами команды, постоянно объяснять свои действия. На самом деле, ПП действительно может раздражат и подходит далеко не всем.
Вы все-таки решились внедрить ПП. Что дальше?
Начните с пиара Расскажите команде, менеджменту и заказчикам зачем вы это делаете, каких сложностей при помощи ПП можете избежать, как сделать так, чтобы ПП работало правильно. Попробуйте внедрять его не сразу, а постепенно. Например, когда будут сложные задания. Во время планирования позволяйте инженерам самим выбрать задание по душе и приглашать коллег присоедениться к работе.
Если в вашей команде есть человек с опытом ПП, постарайтесь, чтобы он поработал по очереди с каждым членом команды. Так делал я, когда настраивал процессы ПП и TDD на ряде новых проектов. Фактически — был ментором и показывал лучшие практики новичкам.
Перед тем, как начать работу, попробуйте определить страхи вашей команды, связанные с внедрением ПП. Объясните, что никто никого не будет осуждать за ошибки или неидеальные решения, а время на кофе останется. Акцентируйте внимание на том, что благодаря такой работе можно выучить много нового и подсмотреть лучшие практики своих коллег: вот Игорь, скажем, делает классные тесты, а Сергей замечательно испарвляет баги. Опыт каждого члена команды станет богаче благодаря ПП, это хорошо не только для понимания продукта, а и для самоорганизации. Конечно, «в плюсе» будут и менеджеры — в паре люди работают эффективнее, ведь валять дурака перед коллегой как-то стыдно.
ПП — не серебрянная пуля, но может быть полезным для некоторых проектов. Расскажите, доводилось ли вам работать в паре? Может, знаете классные ресурсы, чтобы погрузиться в тему? Буду рад пообщаться и обменяться опытом в комментариях.