Драйвер и навигатор в действии (северокорейский вариант методики)

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

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

Skillbox рекомендует: двухлетний практический курс «Я — веб-разработчик PRO».

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».



Здесь второе видео (автор запретил встраивание на сторонних ресурсах, но посмотреть обязательно стоит).

Музыка — не единственная сфера, где сотрудничество двух человек может принести пользу общему проекту. Их гораздо больше, о чем рассказывает профессор социологии из Университета Буффало Майкл П. Фаррелл в своей книге Collaborative Circles: Friendship Dynamics and Creative Work. В частности, он считает, что многие великие идеи появлялись у людей, которые работали в парах: это могли быть ученые, художники, писатели.

В живописи это Моне и Ренуар, в писательстве — Толкин и Льюис, в науке — Крик и Уотсон… Перечислять можно долго. Более того, около половины нобелевских лауреатов в категории «Физиология и медицина» — команды из двух человек.

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

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

Изначально паре может быть сложно слаженно работать, да и вообще такой рабочий процесс многим покажется нелепым. Но здесь, как и везде, нужен опыт. С течением времени работа налаживается и процесс идет уже гладко, практически без проблем.



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

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



Если у драйвера появляется идея, то навигатор и драйвер могут поменяться ролями. Это помогает партнерам работать синхронно. Обмен идеями сродни брейнстормингу, только это более эффективный процесс, плюс уровень ошибок снижается (как показано на диаграмме выше).

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

Парное программирование и рабочий процесс




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

Да, это не выглядит, как идеальный рабочий процесс, но мы не узнаем, насколько он эффективен, пока не попробуем.

Недавно я узнал от однокурсника, что у Atom есть пакет Teletype, который позволяет разработчикам трудиться вместе в режиме реального времени, предоставляя коллегам доступ к своему рабочему столу. Это даже лучше, чем если просто сидеть вместе за одной рабочей станцией, поскольку позволяет находиться в более комфортных условиях и меньше отвлекаться.

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

Период адаптации при переходе одиночек в парное программирование подобен поеданию острого перца. В первый раз все не так, вам не нравится. Но чем чаще вы едите перец, тем скорее он вам начинает нравиться.

В заключение сказанному


Как-то я услышал фразу: «Для того, чтобы идея была реализована в цифре, необходимо, чтобы она прошла через руки другого человека. Этот тип программирования заключается в общении и сотрудничестве». Как мне кажется, именно коммуникация и сотрудничество — две составляющие успешной работы.

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

Skillbox рекомендует:

Комментарии (7)


  1. Cobolorum
    17.01.2019 13:37

    Заголовок правильный. А вот примеры не правильные и музыка даже в 4 руки это не ПП!
    Самое главное в режиме ПП многие просто не могут работать. Даже можно сказать что 90% не могут работать.
    В отличии от музыки где каждый участник дёргает или нажимает свои струны в ПП роли в каждый момент времени четко разделены. В музыке вы может даже играть две молодили параллельно. А в ПП «фокус ввода один». Один тактик –другой стратег. Один писатель –другой ревьюер. Один писатель – другой аналитик. Вы правильно указали эти роли.
    Лет 15 назад когда пытались это сделать выяснилось очень много деталей. Реально нужно как минимум система с двумя независимыми поинтрами на экране (вариант с двумя мышами решает только часть проблем- а надо именно два указателя!). Очень бы наверно помог второй экран со своей клавиатурой, но механизм трансфера кода между экранами надо делать с нуля.
    Но вот вопросы что для каждой пары нужно отдельное помещение это сложно. Партнеры все таки говорят в слух.
    Потом, психологический подбор партнеров это просто супер задача что кадровика что для управляющего.
    Надо признать что ПП выматывает очень сильно 1-2 часа работы, перекур на 30 минут. Но вот производительность при подборе удачной пары реально растет на порядок и что еще не менее важно КАЧЕСТВО кода тоже растет.


    1. boblenin
      17.01.2019 17:30

      Согласно моему личному опыту — очень и очень даже согласен в тем, что вы написали. Нужен напарник, с которым вы психологически совместимы. Качество кода и продуктивность растет. Выматывает гораздо сильнее чем обычная разработка. Насчет интима для партнеров — это решается общением в пол-голоса и более-менее приличная проектировка помещения (перегородки, гуделки белым шумом).


    1. dimka11
      18.01.2019 11:11

      Не проще ли два компьютера рядом поставить и шарить код между ними?


      1. Cobolorum
        18.01.2019 16:50

        Не проще. 2 компа и шара не решает.
        Проблема в том что сейчас весь софт и оконные менеджеры одно фокусные.
        В ПП для примера рабочее место должно реализовывать такой поведенческий шаблон:
        Разработчик (D) – пишет код в редакторе. И предположим допускает ошибку и допускаем что онлайн проверка ее сразу ловит и подчёркивает. Но D не должен отрываться от разработки на решение данной ошибки, у него мысль в потоке реализации глобального алгоритма.
        Ревьюер/вьюер (V) – видя эту ошибку уводит свой указатель на свою часть экрана/второй монитор и предположим изучает сеть или доки на данную тему и находит решение. Видя когда D закончит «алгоритмическую мысль» словесно говорит «есть решении проблемы смотри». Потом ctrl+c/ctrl+v
        Это еще как то можно решить настройками системы. В конце концов два указателя мыши и клавы уже есть лет 10 как.
        Или более сложный вариант, но требующий уже специализированной IDE где V может сразу править код за D, но тут уже нужен редактор с двумя фокусами ввода.

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


  1. dipsy
    17.01.2019 17:54

    А три головы наверное ещё лучше. Были ли эксперименты?


  1. ni-co
    17.01.2019 18:29

    Извиняюсь, что немного в сторону от темы, но
    картинка с корейцами напомнила фильм «Пароль рыба-меч». )))
    Психологически. Поймет кто смотрел.


    1. adson
      18.01.2019 10:25

      совсем уж маловероятно, что там шведка под столом сидит