Драйвер и навигатор в действии (северокорейский вариант методики)
От переводчика: сегодня публикуем для вас статью Эндрю Спрула, специалиста по Data Science. Он рассказывает о преимуществах парной работы программистов над одним и тем же проектом.
Я часто слышу, как люди говорят, что лучше всего они работают в одиночку. Я понимаю, что некоторые идеи и методы, которые подходят для одного человека, не годятся для другого. Но все же мне близка поговорка «Одна голова хорошо, а две — лучше». Под катом два видео, которые показывают, насколько хорошо над одной задачей могут работать два человека. Это просто гармония — и в прямом, и в переносном смысле.
Skillbox рекомендует: двухлетний практический курс «Я — веб-разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Здесь второе видео (автор запретил встраивание на сторонних ресурсах, но посмотреть обязательно стоит).
Музыка — не единственная сфера, где сотрудничество двух человек может принести пользу общему проекту. Их гораздо больше, о чем рассказывает профессор социологии из Университета Буффало Майкл П. Фаррелл в своей книге Collaborative Circles: Friendship Dynamics and Creative Work. В частности, он считает, что многие великие идеи появлялись у людей, которые работали в парах: это могли быть ученые, художники, писатели.
В живописи это Моне и Ренуар, в писательстве — Толкин и Льюис, в науке — Крик и Уотсон… Перечислять можно долго. Более того, около половины нобелевских лауреатов в категории «Физиология и медицина» — команды из двух человек.
Ну а в наше время отличные результаты дает «парное программирование», которое «Википедия» описывает как agile-методику разработки программного обеспечения, которая заключается в работе двух программистов за одной рабочей станцией. Один из них, драйвер, пишет код, второй, наблюдатель, следит за процессом и читает каждую набранную строку. Программисты часто меняются ролями.
Эта методика не имеет отношения к работе по модели «учитель-ученик», речь идет о совместной работе двух равных специалистов. Один из них может иметь больший опыт, но работают они одинаково, права равны. В целом, идея заключается в том, что два человека находят решение быстрее, чем один.
Изначально паре может быть сложно слаженно работать, да и вообще такой рабочий процесс многим покажется нелепым. Но здесь, как и везде, нужен опыт. С течением времени работа налаживается и процесс идет уже гладко, практически без проблем.
Повторюсь, в парном программировании две роли: драйвер и навигатор. Главная задача первого — следить за деталями кода, реализовывать идеи, превращая их в строки кода. Драйвер и навигатор должны обсуждать идеи и проблемы.
Навигатор уделяет внимание каждой набранной строке, и это внимание не рассеянное, поскольку ему не требуется набирать текст. Главная цель навигатора — доносить четкие идеи драйверу. Навигатор должен давать драйверу инструкции с определенным уровнем абстракции так, чтобы тот был в состоянии реализовывать их максимально эффективно.
Если у драйвера появляется идея, то навигатор и драйвер могут поменяться ролями. Это помогает партнерам работать синхронно. Обмен идеями сродни брейнстормингу, только это более эффективный процесс, плюс уровень ошибок снижается (как показано на диаграмме выше).
Я могу посоветовать специалистам, которые работают в паре, иногда прерываться и задавать друг другу вопросы. Это помогает мыслить в одном направлении, понимать друг друга и работать качественно.
Парное программирование и рабочий процесс
Изучая вопрос парного программирования, я обнаружил, что существует несколько стратегий для такой работы. Некоторые из вариантов могут быть найдены здесь. Одна из наиболее интересных стратегий называется «Пинг-понг спарринг». Она работает следующим образом:
- Программист А пишет новый тест и видит, что он не работает.
- Программист Б добавляет код, который необходим для того, чтобы пройти тест.
- Программист Б пишет новый тест и видит, что он не работает.
- Программист А добавляет код, который необходим для того, чтобы пройти тест.
- Возвращаемся.
Да, это не выглядит, как идеальный рабочий процесс, но мы не узнаем, насколько он эффективен, пока не попробуем.
Недавно я узнал от однокурсника, что у Atom есть пакет Teletype, который позволяет разработчикам трудиться вместе в режиме реального времени, предоставляя коллегам доступ к своему рабочему столу. Это даже лучше, чем если просто сидеть вместе за одной рабочей станцией, поскольку позволяет находиться в более комфортных условиях и меньше отвлекаться.
И не забывайте: ролями в течение дня необходимо меняться. При этом вы не можете использовать таймер, поскольку он будет мешать рабочему процессу. Многие считают, что вы должны меняться ролями в пределах интервала в 30 минут. Но здесь все субъективно.
Период адаптации при переходе одиночек в парное программирование подобен поеданию острого перца. В первый раз все не так, вам не нравится. Но чем чаще вы едите перец, тем скорее он вам начинает нравиться.
В заключение сказанному
Как-то я услышал фразу: «Для того, чтобы идея была реализована в цифре, необходимо, чтобы она прошла через руки другого человека. Этот тип программирования заключается в общении и сотрудничестве». Как мне кажется, именно коммуникация и сотрудничество — две составляющие успешной работы.
Сам я более продуктивен, когда работаю в паре с кем-то. Мой опыт музыканта подсказывает, что играть в ансамбле лучше, чем быть сольным исполнителем. Это не потому, что я зависим от другого человека, скорее, моя уверенность в успехе растет, когда я вижу, что общий труд более эффективен. Сейчас из меня лучший навигатор, чем драйвер, но я постепенно совершенствуюсь. Надеюсь, что эта статья поможет вашим будущим проектам.
Skillbox рекомендует:
- Практический курс «Мобильный разработчик PRO».
- Онлайн-курс «Профессия frontend-разработчик».
- Практический годовой курс «PHP-разработчик с 0 до PRO».
Cobolorum
Заголовок правильный. А вот примеры не правильные и музыка даже в 4 руки это не ПП!
Самое главное в режиме ПП многие просто не могут работать. Даже можно сказать что 90% не могут работать.
В отличии от музыки где каждый участник дёргает или нажимает свои струны в ПП роли в каждый момент времени четко разделены. В музыке вы может даже играть две молодили параллельно. А в ПП «фокус ввода один». Один тактик –другой стратег. Один писатель –другой ревьюер. Один писатель – другой аналитик. Вы правильно указали эти роли.
Лет 15 назад когда пытались это сделать выяснилось очень много деталей. Реально нужно как минимум система с двумя независимыми поинтрами на экране (вариант с двумя мышами решает только часть проблем- а надо именно два указателя!). Очень бы наверно помог второй экран со своей клавиатурой, но механизм трансфера кода между экранами надо делать с нуля.
Но вот вопросы что для каждой пары нужно отдельное помещение это сложно. Партнеры все таки говорят в слух.
Потом, психологический подбор партнеров это просто супер задача что кадровика что для управляющего.
Надо признать что ПП выматывает очень сильно 1-2 часа работы, перекур на 30 минут. Но вот производительность при подборе удачной пары реально растет на порядок и что еще не менее важно КАЧЕСТВО кода тоже растет.
boblenin
Согласно моему личному опыту — очень и очень даже согласен в тем, что вы написали. Нужен напарник, с которым вы психологически совместимы. Качество кода и продуктивность растет. Выматывает гораздо сильнее чем обычная разработка. Насчет интима для партнеров — это решается общением в пол-голоса и более-менее приличная проектировка помещения (перегородки, гуделки белым шумом).
dimka11
Не проще ли два компьютера рядом поставить и шарить код между ними?
Cobolorum
Не проще. 2 компа и шара не решает.
Проблема в том что сейчас весь софт и оконные менеджеры одно фокусные.
В ПП для примера рабочее место должно реализовывать такой поведенческий шаблон:
Разработчик (D) – пишет код в редакторе. И предположим допускает ошибку и допускаем что онлайн проверка ее сразу ловит и подчёркивает. Но D не должен отрываться от разработки на решение данной ошибки, у него мысль в потоке реализации глобального алгоритма.
Ревьюер/вьюер (V) – видя эту ошибку уводит свой указатель на свою часть экрана/второй монитор и предположим изучает сеть или доки на данную тему и находит решение. Видя когда D закончит «алгоритмическую мысль» словесно говорит «есть решении проблемы смотри». Потом ctrl+c/ctrl+v
Это еще как то можно решить настройками системы. В конце концов два указателя мыши и клавы уже есть лет 10 как.
Или более сложный вариант, но требующий уже специализированной IDE где V может сразу править код за D, но тут уже нужен редактор с двумя фокусами ввода.
Ответ про «три головы» это не пойдет по причине что человек может воспринимать с одного входа-органа чувств один поток информации. Можно слушать и видеть, но нельзя слушать одновременно двоих или смотреть одновременно на два монитора. А про две клавиатуры пол левую и правую это будет просто фантастика.