Май 12, 2015 - 0 Comments - Без рубрики -

Подводные камни парного программирования

Парное программирование в каком-то смысле напоминает парное патрулирование, когда у тебя есть комрад, который, наблюдая за ситуацией под другим углом, может прикрыть спину и спасти жизнь. На службе, как и в офисе, редко бывают лишними дополнительная пара глаз и толковая голова, о чем вовремя смекнули agile-евангелисты. И теперь двое за компом — это уже не тунеядцы, но адепты относительно нового движения, которое, с одной стороны, призвано увеличить качество разработки, но с другой — оставляет поле для вопросов. Когда включать парное программирование? Выгодно ли это? Нужно ли оно вообще?

Парное программирование — это когда за одним компьютером сидят два сотрудника: один кодит (driver), второй контролирует (observer). Они могут время от времени меняться местами. Kent Beck дает более простое определение: «All production code is written with two programmers at one machine».

В теории такая практика позволяет разработчикам добиться нескольких вещей:

  1. Улучшить качество кода. Вторая пара глаз, если не спит, то вылавливает ошибки еще «теплыми». Раскрыть преступление по горячим следам легче и быстрее, чем после, поэтому в данном случае парное программирование позволяет здорово сэкономить время.
  2. Улучшить дизайн приложения. Как правило, двое принимают более удачные архитектурные и дизайнерские решения. Особенно если речь идет о сложных задачах, требующих нестандартного, креативного подхода. При этом, судя по исследованию, проведенному в одной испанской компании, парный дизайн не так эффективен, как парный кодинг.
  3. Перенять опыт. В первую очередь это касается джунов, которым важно научиться думать как опытный программист. В данном случае парное программирование — это, по сути, отношения ментор-ученик.
  4. Получить знания. Даже для уверенного разработчика «въезд» в новый проект требует некоторого времени. Можно, конечно, долбить стену в одиночку или регулярно заваливать вопросами коллег, но продуктивней будет провести несколько 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, хоть где. Важно другое: отдавать себе отчет в том, что такой вид программирования требует определенной слаженности команды (она будет расти с каждым часом), и что он не является панацеей от всех бед проекта. Парным программированием можно пересолить, как на этом видео:


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Человек ? *