Парное программирование в каком-то смысле напоминает парное патрулирование, когда у тебя есть комрад, который, наблюдая за ситуацией под другим углом, может прикрыть спину и спасти жизнь. На службе, как и в офисе, редко бывают лишними дополнительная пара глаз и толковая голова, о чем вовремя смекнули agile-евангелисты. И теперь двое за компом — это уже не тунеядцы, но адепты относительно нового движения, которое, с одной стороны, призвано увеличить качество разработки, но с другой — оставляет поле для вопросов. Когда включать парное программирование? Выгодно ли это? Нужно ли оно вообще?
Парное программирование — это когда за одним компьютером сидят два сотрудника: один кодит (driver), второй контролирует (observer). Они могут время от времени меняться местами. Kent Beck дает более простое определение: «All production code is written with two programmers at one machine».
В теории такая практика позволяет разработчикам добиться нескольких вещей:
- Улучшить качество кода. Вторая пара глаз, если не спит, то вылавливает ошибки еще «теплыми». Раскрыть преступление по горячим следам легче и быстрее, чем после, поэтому в данном случае парное программирование позволяет здорово сэкономить время.
- Улучшить дизайн приложения. Как правило, двое принимают более удачные архитектурные и дизайнерские решения. Особенно если речь идет о сложных задачах, требующих нестандартного, креативного подхода. При этом, судя по исследованию, проведенному в одной испанской компании, парный дизайн не так эффективен, как парный кодинг.
- Перенять опыт. В первую очередь это касается джунов, которым важно научиться думать как опытный программист. В данном случае парное программирование — это, по сути, отношения ментор-ученик.
- Получить знания. Даже для уверенного разработчика «въезд» в новый проект требует некоторого времени. Можно, конечно, долбить стену в одиночку или регулярно заваливать вопросами коллег, но продуктивней будет провести несколько pair-programming сессий, которые прольют свет на то, вокруг каких компонентов всё вращается, где понаставлены костыли и каких шкафов со скелетами лучше избегать.
Для работодателя в парном программировании есть один плюс, который одновременно является минусом для разработчика — это размазывание знаний о проекте ровным слоем по команде. Чтобы не было незаменимых людей. Также в копилку плюсов идет дополнительный тим-билдинг и стимул для сотрудников находить общий язык.
Еще одним плюсом иногда называют повышение производительности труда — мол, если за спиной ощущается всевидящее око штурмана, то ведущий не будет лазить по бложикам и форумам, смиренно отдавшись работе. Этот миф можно разоблачить двумя рандомными примерами: если поставить в пару двух раздолбаев, то их производительность труда станет не расти, а падать; если ведущий привык сидеть в чатиках и в фейсбуке, то он всё равно будет в них сидеть. Особенно если штурман ниже рангом. Так что с производительностью здесь не всё так однозначно, — всё зависит от людей.
«Помощь друга» не является новой идеей организации рабочего процесса, — те же летчики и копы давно уже работают в парах. Но в среде программистов эта идея всё еще относительно свежа и необжита. Так что пора пролить немного эмпирического света на особенности этой практики, чтоб не наломать дров раньше времени.
Что следует учесть перед началом парного программирования:
— Больше человеко-часов на задачу.Для программиста это ничего не значит: солдат спит — служба идёт. Но для работодателя это возросшие траты на работу двух человек вместо одного (в среднем pair-programming обходится на 15% дороже). Тогда как результат в виде меньшего количества багов и более удачного дизайна, который в итоге может компенсировать увеличенное число затраченных человеко-часов и даже удешевить продукт, не всегда очевиден.
— Разные характеры.С одной стороны может показаться, что если коллеги не сошлись во мнениях, то между ними не может возникнуть тех дружеских отношений, которые помогают в парном программировании. Или что человек, который одновременно открывает десятки окон и вкладок и пробует сразу несколько вариантов, не уживется в паре с «медленным программистом», который долго изучает один-единственный метод, прежде чем в один присест написать решение. Но исследованиео влиянии характеров коллег на их работу в паре утверждает, что проблемы как таковой нет:
«Personality may be a valid predictor for long-term team performance. However, we found no strong indications that personality affects pair programming performance or pair gain in a consistent manner, especially when including predictors pertaining to expertise, task complexity, and country.»
Если добавить к этому тот факт, что обычно пары регулярно меняются, да и работают вместе ограниченный период времени, то роль особенностей характеров становится ещё меньше.
Но на этот счет есть и другие мнения: некоторым людям программирование в паре дается тяжело, потому что требует определенной зрелости и смелости, не говоря уже о том, что часто свой кодникому не хочется давать.
— Различный уровень мастерства.Грубое деление разработчиков на новичков и экспертов дает три варианта комбинаций: эксперт — эксперт, эксперт — новичок, новичок — новичок.
Эксперт — эксперт.С одной стороны, может показаться, что два мегамозга, работающих над одной задачей — идеальная комбинация для решения любых задач. Но исследованияГонконгского политеха говорят о том, что это не совсем так. Креативный подход в такой паре может страдать, так как эксперты обычно не ставят под сомнение общепринятые практики.
Эксперт — новичок.Фактически, это отношения ментор-ученик, которые, тем не менее, будут полезны не только джуну, но и ментору. Новичок будет обучаться, задавая вопросы, а учитель будет обучаться, передавая опыт (лат. — docendo discimus — обучая, обучаюсь, — Сенека). Кроме того, джун будет задавать много «глупых» вопросов, подталкивая эксперта более креативно подходить к решению задач.
Новичок — новичок.Эта пара обычно не только работает намного быстрее и качественнее, чем одинокий новичок, но и эффективнее, чем даже пара эксперт-эксперт.
— Гигиена сотрудников.Не каждый перец захочет сидеть рядом с потным коллегой, у которого плохо пахнет изо рта. Конечно, публика сегодня потихоньку становится цивилизованней, открывая для себя шампунь, мыло, дезодорант и зубную щетку, но в офисах всё ещё встречаются динозавры. При этом проблема гигиены здесь может иметь и обратную сторону в виде чрезмерной брезгливости к чужим жирным пальцам, которые тарабанят твою невинную клавиатуру.
— Ограниченное время.Согласно исследованию, опубликованному в 2009 году в журнале IEEE Transactions on Software Engineering, оптимальное время для работы в паре — от 1.5 до 4 часов. Иначе наступает ментальное истощение. При этом пары следует регулярно тасовать.
— Сложность концентрации.Не так-то легко одновременно думать, говорить и набирать код. Слушать чью-то речь и кодить — аналогично. Если один напарник явно подкованнее другого, то второй будет, к тому же, нервничать, полагая, что он работает слишком медленно, забирая у эксперта лишнее время. Эта нервозность вкупе с потребностью обрабатывать чью-либо речь будет мешать сосредоточиться.
— Не для всех типов задач.Парное программирование хорошо работает лишь для определенного рода сложных проблем, требующих креативного подхода. В случае стандартной задачи, например, тривиального CRUD, парная работа теряет свою эффективность. Негоже из пушки палить по воробьям.
Problems, officer?
Главный признак того, что в паре что-то не так, — молчание. Тишина может говорить о двух вещах: либо один из разработчиков преклоняется перед мастером и боится даже слово сказать, либо же ему абсолютно фиолетово происходящее, и он коротает время. Кто-то должен всё время говорить и комментировать происходящее. Особенно это важно в работе с джуном, который через озвученные поводырем комментарии, начнет схватывать образ его мышления. Получается почти как частный урок программирования, за который ещё и доплачивают.
Совсем не обязательно становиться адептом Agile, чтобы практиковать парное программирование, — использовать его можно хоть на waterfall, хоть где. Важно другое: отдавать себе отчет в том, что такой вид программирования требует определенной слаженности команды (она будет расти с каждым часом), и что он не является панацеей от всех бед проекта. Парным программированием можно пересолить, как на этом видео: