Тот, кто придумал термин mob programming, явно не спец в маркетинге. Кто захочет вступить в банду? Слово mob вызывает образы разбитого стекла и разграбленных магазинов — население Спрингфилда выстроилось в ряд с вилами и факелами.
Действительно, банда или толпа — это нечто противоположное тому, какой хочется видеть успешную сессию программирования. Толпа дезорганизована, склонна к опрометчивым решениям, злится и не желает идти на компромисс. Но групповое программирование не имеет к этому отношения.
Так что же такое групповое программирование?
Что такое групповое программирование? Попросту говоря: это три (или более) разработчика и одна клавиатура. Нет, это не те странные вещи, которые вы видели в интернете. Речь идет о совместной работе и выпуске высококачественного программного обеспечения.
Поскольку большинство программистов бросает в пот от одной мысли о совместной работе с другими людьми, то более подробно расскажу, как это выглядит. Представьте, что у нас есть разработчик Стив. Он работает над приложением, где пользователи могут просматривать рецепты. Однажды Стиву поручено добавить в приложение функцию «Избранное». С помощью этой функции пользователи могут сохранять рецепты в собственном списке под названием «Моё избранное». Если они хотят посмотреть сохранённый рецепт, то просто открывают список «Избранного» и выбирают его.
Стив хочет использовать групповое программирование для реализации своей функции, поэтому бронирует переговорную и просит своих коллег Джона и Сару присоединиться к его группе. Джон и Сара появляются на встречу с ноутбуками, готовые к работе над реализацией функции «Избранного».
В данный момент Стив должен установить определённые правила (да, у мобов есть правила). Они могут быть примерно такими:
- В любой момент времени один человек является «водителем» (driver). Это человек с клавиатурой и мышью. Единственный, кому разрешено изменять код.
- Все остальные берут на себя роль «штурманов» (navigator). В то время как водитель тратит много времени на физический набор текста, у штурманов есть всё необходимое время, чтобы обдумать, просмотреть, обсудить, описать. И это именно то, что они должны делать.
- Все часто меняются местами. Нет, это не какие-то игры, как в детском саду. Если люди слишком долго сидят в одной роли, то могут устать. Если же у них есть любимая роль, то могут заскучать без неё.
И это всё — теперь вы знаете, что такое групповое программирование. Добавьте его в свое резюме.
Хорошо, я понял, что это такое, расскажи больше
Если вы дочитали досюда, то вероятно думаете: «Почему этот парень объясняет групповое программирование? Google и так выдаёт 500 объяснений». Ну просто я занимаюсь этим каждый день в течение пяти месяцев. И вот что я узнал:
Это действительно неплохо
Помню, когда впервые узнал о групповом программировании. Мне было 19, в комнате толпилась куча студентов, не пользующихся дезодорантом, в здании, которое выглядело так, словно оно предназначено под снос (забавно, но так оно и вышло). Профессор только что закончил объяснять курс по структурам данных. В конце он пошутил: «Вы можете работать в одиночку или в группе — в индустрии все работают в группах, они называют их мобами». Боже мой, подумал я, и во взрослой жизни есть групповая работа.
Удивительно, но каждый раз, когда я объясняю концепцию группового программирования новому человеку, кажется, то же чувство страха пробегает по его лицу. Оставь себе свою групповую работу.
Но вот плохая новость — вы уже занимаетесь групповой работой. На работе у вас есть коллектив, вы обращаетесь к коллегам за помощью, они рассматривают вам код. Требуется сочетание всех усилий для определения, будет проект успешным или нет.
И тогда можно понять, что такое групповое программирование. Это не больше групповой работы, а столько же. Разница в том, что все взаимодействия с коллегами станут очень лёгкими — больше никогда не придётся гадать, чем они занимаются, никогда.
Групповое программирование помогает лучше узнать своих коллег
Если вы когда-нибудь оторвёте глаза от монитора, то можете обнаружить вокруг других людей. Оказывается, у них тоже жизнь! Если серьёзно, если взаимодействовать с коллегами с утра до вечера, то узнаете их намного лучше.
Поскольку программирование — это работа, а не клуб по интересам, мы должны быть более практичными. Хорошо взаимодействующие команды лучше справляются с работой. Это факт, отсюда все эти упражнения по тимбилдингу и выезду на природу. Командам в мобах не нужен тимбилдинг, потому что они уже хорошо работают вместе.
Удалённость — не причина уклониться
«Но я работаю удалённо, меня никогда нет в офисе, чтобы вступить с кем-то в моб». Плохие новости, приятель, я всё время работаю удалённо. Оказывается, в этой штуке под названием 21-й век приложений для удалённой работы вагон и маленькая тележка. Мой любимый — видеозвонок Slack. Там есть все необходимые функции: вы можете расшарить экран, когда выступаете в роли водителя, и говорить голосом в роли штурмана. Может, ваша компания не использует Slack, а что-нибудь вроде WebEx, где организация звонка занимает три года работы научно-исследовательской группы. В этом случае просто открой сессию в Appear.in, кончай искать причины отлынивать от продуктивной работы.
Я больше времени программирую, потому что меньше туплю
Как выглядит программирование в одиночестве
Итак, я собираюсь сделать признание — я плохо разбираюсь в CSS. И не просто плохо, а конкретно ПЛОХО. Так что можете представить, если я работаю над проектом, скажем, над своим сайтом (скоро), то часами стучусь головой о стену, пытаясь понять, почему мои div'ы не выравниваются (правда, почему?).
В групповой работе всё иначе: я не застреваю на CSS, потому что всегда есть вторая и третья пара глаз, чтобы помочь. Значит, я меньше времени стучусь головой о стену и больше времени уделяю решению проблем.
Нет такого понятия, как «мой кусочек» кода
Позвольте рассказать историю ужасов, историю конкретного фрагмента кода. Ну вы знаете такие. Изначально его написал Фрэнк, просто Фрэнк. Когда находились баги, Фрэнк их исправлял. Когда нужны были новые функции, Фрэнк их добавлял. Никто другой в команде не знал, как работает код. Только то, что он должен делать. Если он не делал что надо, рядом есть Фрэнк. Ну вот, однажды Фрэнка не оказалось рядом. Он нашёл новую работу и получил большую прибавку к зарплате, молодец. А вы остались с куском системы, который никто не понимает и никто не хочет трогать, наслаждайтесь.
Группы работают сообща, так что никогда в коде не останется тайн и загадок. Если загадочный фрагмент есть сейчас, то натравите на него группу программистов с автором этого кода — и они положат тайне конец.
В качестве вывода
Итак, вот это я узнал (пока) о групповом программировании. Честно говоря, меня по-настоящему удивило, насколько это приятный способ для работы и решения сложных технических проблем. Вероятно, сейчас вы обеспокоены, что я упустил один важный положительный (или отрицательный) момент — к счастью, для этого есть раздел комментариев.
Комментарии (27)
Cobolorum
06.03.2018 15:50+7Прикольно когда проходит 18 лет и люди открывают то что было открыто. Из парного/группового программирования были сделаны выводы:
1 Производительность действительно растет и не в 2 раза, а раз в 5.
2 Два нормально, но 3 уже много. Хотя иногда надо 3 человек для сильно смешанного кода для примера когда интенсивно использует SQL.
3 Не каждый программист может работать в парном программировании.
4 Подбор групп это искусство и отдельная тема, скорее всего для психологии.
5 Группам нужны отдельные кабинеты. В опенспейс их не посадишь, будет стоять непрерывный гул и ор. ЭТО основная проблема ПП!
6 Режим работы, 2 часа пишем код, час отдыхаем.
7 Постоянно поддерживать обратную связь-отечность. Нельзя что бы один садился на шею другому. Нельзя что бы фиксировались роли ведущий-ведомый, они должны меняться.Hixon10
06.03.2018 22:031 Производительность действительно растет и не в 2 раза, а раз в 5.
А можно пруф? Часто читал о том, что она растёт, но с куда хужем коэфициентом (что-то типа 2 парных разработчика пишут код, как 1.5 программиста, работающих отдельно).
hippoage
07.03.2018 02:05Как по мне сильно зависит от сложности задачи и известности технологий/необходимых частей кода.
Если все по накатанной, то смысла вдвоём программировать нет.
DnV
07.03.2018 03:03Скорее нечто среднее по сложности. Действительно сложные задачи можно хоть вдесятером долго и безуспешно «штурмовать» пока в одиночку по-настоящему не закопаешься.
bro-dev
07.03.2018 05:50Мб выигрыш за счет того, что не нужно организовывать группу, то есть двое могут работать с менеджером, ну или сами будут на это тратить время, а это уже не 2х.
С другой стороны если 2 работают над разными вещами, то да будет чистые 2х.
endorphin
06.03.2018 17:12почему бы не назвать статью «Это заставит ваши глаза вытекать вместе с кровью»
aamonster
06.03.2018 20:24А не проще нанимать людей, которые бОльшую часть времени смогут работать в одиночку?
Мой опыт — работа в группе "работает", когда надо решить действительно сложную задачу; когда надо разобраться в legacy-алгоритме (или структуре данных); когда надо ввести в курс новичка; когда неясно, каким именно путём лучше решать задачу. В общем, когда есть шанс на чём-то застрять.
Но, к сожалению, есть очень много рутины, где выигрыш от работы группой невелик. ("К сожалению" — т.к. это не самая интересная часть работы).
Ну и да, если у вас программисты могут собраться группой, обсудить, решить сложные задачи и раскидать между собой простые — то они порвут в клочья вашего трёхликого.
interprise
06.03.2018 22:02Это правда очень эффективно, но я не думаю, что мне смогут платить столько, чтобы я согласился.
evis_dev
06.03.2018 22:39Если серьёзно, если взаимодействовать с коллегами с утра до вечера, то узнаете их намного лучше. Поскольку программирование — это работа, а не клуб по интересам...
… то внезапно может оказаться, что ваши коллеги — это люди с кучей несовместимых с вами тараканов в голове. Иными словами, совершенно не те люди, с которыми вы хотите непрерывно проводить 8+ часов 5 дней в неделю.
Я больше времени программирую, потому что меньше туплю
Конкретно водитель больше программирует, но сомневаюсь, что больше, чем три человека.
Нет такого понятия, как «мой кусочек» кода
Для избавления от этой проблемы обязательные code-review куда эффективнее.
VladC
06.03.2018 23:20Могу себе представить только один вариант парного программирования — если твой партнёр является твоим давним другом и вы давно вместе болеете программированием и у вас есть опыт совместной разработки, в случае с простыми коллегами больше чем уверен, что затея провалится и ещё меньше шансов на успех у коллег, чьё сотрудничество было назначено другими людьми. Вообще странная идея, почему бы тогда во всех профессиях так не делать — например 2 руководителя, один приглядывает, другой руководит, потом поменялись, звучит не менее бредово?
AbstractGaze
07.03.2018 07:02+1А с чего вы взяли что такого нет? Что из себя по вашему представляет обычное принятие решений, когда собираются 2+ человека и обсуждают плюсы и минусы? Это и есть парное решение вопроса, и все знают что две головы в этом плане всегда лучше чем одна. Даже, если это какой то бытовой вопрос.
evnuh
07.03.2018 02:22водитель
штурман отвлекает водителя смешной картинкой
водитель не справляется с управлением
- все втроём разбиваются об монитор, были не пристёгнуты
Hardcoin
07.03.2018 02:27Читаю комментарии, удивляюсь. Парное программирование намного проще, чем кажется. Это не какая-то катастрофа или борьба за роли. Просто берете и делаете. И действительно, когда не надо набирать, думается немного легче. Насчёт удвоения скорости, правда, не могу сказать, не замеряли.
mad_nazgul
07.03.2018 07:37Есть опыт парного программирования
В основном положительный.
Но он не подходит для open space.
Т.к. во время процесса производится много шума.
От горячего обсуждения проблемы, до громкого хохота.
Toshiro
07.03.2018 08:36-2Всегда восхищало — как люди умеют взять банальный и рутинный рабочий процесс, дать ему броское название и сделать вид, что это откровение.
Вроде же всегда было естественным, что разработчики обращаются друг к другу за помощью в какие-то моменты и естественным путем образуется консилиум для решения какой-то замороченной задачи.
Статья похожа на "давайте если кузнец не может один выковать изделие, называть это ПАРНОЙ КОВКОЙ!" +)))
alexey_prokopyev
07.03.2018 09:48+1Мы на работе иногда пишем код вдвоем. Это реально работает: 2 головы придумают красивое решение проблемы быстрее, чем одна; 2 пары глаз вычитывают код и делают меньше опечаток; 2 человека хорошо знают код и разбираются в нем, а значит упрощается поддержка.
Но не все готовы так делать =)
eignatik
07.03.2018 10:58Мне кажется, что статья немного странно написана, но на самом деле парное программирование довольно занятная вещь. Я ее довольно часто практикую на работе, когда есть какая-то сложная задача и вдвоём ее решить получается гораздо быстрее. Еще иногда практикуем парное программирование в open source проектах. На самом деле это позволяет получить некоторый прирост скорости и что самое главное, обычно это влияет на качество кода в хорошую сторону. Меньше code smells допускаешь, так как сразу происходит и ревью кода. Но не всегда парное программирование уместно. ИМХО. Есть кейсы, когда правда лучше закопаться самому.
KVL01
07.03.2018 14:09Дык, а с кем программировать? Если напарник слаб, то теряешь время на его обучение и исправление косяков. Если напарники одинаково сильны, то и до мордобоя недалеко. Может, если все одинаково слабы, то что-то и получится, но смысл? Количество не перерастёт в качество.
Вот от секретаря с навыками кодинга я бы не отказался – свалил на него рутину и думаешь о высоком…
cheripocker
07.03.2018 15:16Олимпиадники смеются над эти «открытием».
В жизни не довелось групповым заниматься, но парным — да.
Помогает, но man hours в среднем больше конечно уходит, чем по отдельности.
qw1
08.03.2018 12:03Олипиадники группой 2-3 человека обсуждают решение, потом один садится кодить, а остальные берутся обсуждать следующую задачу. Точно так же можно обсудить архитектуру и алгоритмы отдельно в переговорке, потом вернуться по рабочим местам и кодить каждый свою часть.
spam312sn
07.03.2018 21:40+1Получил массу удовольствия от группового программирования, когда показывал экран своим коллегам используя Discord. Производительность действительно выросла в несколько раз. Во-первых, тратиться меньше времени на обдумывание всех составляющих программы — не держится абсолютно всё в голове и пока я делаю какую-то часть, мои коллеги обдумывают другую и предлагают свои решения задачи, что значительно облегчает работу. Во-вторых, проговаривая почти каждое своё действие, лучше понимается алгоритм и самому и коллегам. Ну и в-третьих, это весело — можно и что-нибудь интересное обсудить в процессе разработки и более слабым объяснить что-то сложное или новое.
xadd
«Как выглядит программирование в одиночестве» — Экстравертам не позавидуешь…