Экстремальное программирование включает более 10 разнообразных приемов — TDD, игра в планирование, «заказчик всегда рядом» и т.д. Сегодня речь пойдет о парном программировании. Предлагаем читателям блога beeline cloud поделиться своим мнением об этом приеме! Практиковали ли вы когда-нибудь парное программирование? Повысило ли это эффективность разработки? Расскажите нам в комментариях!
Жизнь в Кремниевых доках (Ирландском аналоге Кремниевой долины) имеет свои неоспоримые преимущества. Обилие высокотехнологичных компаний и бесконечная череда интеллектуальных тусовок под их сводами создают прекрасные условия для полезных встреч. Перемещаясь из компании в компанию, в коворкинги и на конференции, вы не только встретите нынешних, прошлых и будущих коллег, но и получите возможность познакомиться с различными методами работы и обучения. И не раз вам доведется услышать о всяческих стратегиях совместной работы. Пожалуй, одной из самых разрекламированных является парное программирование.
С концепцией парного программирования я познакомился ещё в самом начале своей карьеры. Одни мои коллеги были ярыми её приверженцами, другие не видели в ней явных преимуществ, либо считали, что таковые вообще отсутствуют. Проведя более десяти лет в сфере разработки программного обеспечения, я пришел к выводу, что ни одна из групп не была права. Парное программирование в неумелых руках способно принести немало вреда. Однако в определенных ситуациях его полезность не вызывает сомнений.
Детальный взгляд на концепцию
Концептуально парное программирование подразумевает именно то, что заключается в этих словах. Два инженера работают с одним исходным кодом, над одной и той же задачей. Более того — как правило, сидят они за одним компьютером. Правда, рост популярности удаленной работы внес сюда свои коррективы.
Абстрагируясь от условностей, о ПП можно сказать следующее:
Временные затраты на разработку могут увеличиться на 200%. Казалось бы, откуда такие большие цифры? Ну, пусть время увеличится на 100%. В конце концов, над задачей работает всего один дополнительный сотрудник. Однако это слишком наивный подход. В реальности сеансы парного программирования, как правило, стоят вдвое дороже, поскольку зачастую каждый инженер отстаивает свой собственный подход. Во многих случаях имеет место и дисбаланс навыков. Например, старший и младший инженеры выполняют одну и ту же задачу. Старший инженер, чтобы приспособиться к младшему, намеренно замедляется до его темпа. Это нормально и даже необходимо, поскольку в парном программировании предусматриваются и элемент преподавания, и факт приобретения дополнительных навыков. То же самое, кстати, наблюдается и в тех случаях, когда два человека плюс-минус одинакового уровня работают над одной и той же задачей, но один из них плохо знаком с кодовой базой.
Теоретически получившийся код должен содержать меньше ошибок. По идее, так и должно быть. Ведь четыре глаза видят больше, чем два, не так ли? В действительности все может сложиться совсем иначе. Этот тезис справедлив, только если в сеансе парного программирования участвуют два очень сильных разработчика. Аналогичная ситуация с двумя джунами не принесет никаких преимуществ.
Ведущий и наблюдатель. Традиционно программисты меняются ролями в течение сеанса. Кто-то раз в 20 минут, кто-то — каждый час. Нередко возникают ситуации, когда один человек большую часть времени ведет, а второй смотрит. Причины могут быть разными и чаще всего зависят от контекста. Главное, что два человека активно погружены в решение проблемы. Переключение внимания — в целом отличный, полезный навык — не приведёт к положительному результату, а ухудшит восприятие. Именно поэтому многие инженеры склонны отключать все остальные каналы связи во время парного программирования.
Список, возможно, не самый исчерпывающий, но он затрагивает ключевые аспекты, заслуживающие нашего пристального внимания. Мне доводилось видеть множество команд инженеров, выступающих за парное программирование, и при этом не демонстрирующих никаких ощутимых преимуществ. На деле это, как правило, прагматичные команды, в которых парное программирование – не постоянная практика, а инструмент, применяемый от случая к случаю. Способ достижения более высокой скорости разработки или общего повышения производительности команды.
Регулярная практика парного программирования
Многие слышали поговорку: «Когда у тебя есть только молоток, все остальное кажется гвоздем». Это справедливо и для парного программирования. Если прибегать к нему постоянно, команды начинают полагаться на него буквально во всем. ПП внезапно становится чуть ли не единственным способом привлечения новых людей, сбора команд, актуализации документации, наставничества и обмена знаниями. ПП перестает быть инструментом и становится частью культуры. Образом жизни программистов.
Парное программирование как ситуативный инструмент
Для достижения более высокой скорости, наращивания опыта разработчиков, формирования кросс-функциональных, гибких команд с высокой производительностью существует огромное количество инструментов. В современной разработке программного обеспечения парное программирование — один из них. Но использовать его нужно точечно.
Основываясь как на собственном, так и на чужом опыте, опишу сценарии, в которых я вижу реальную ценность парного программирования:
В качестве вводной сессии, когда к команде присоединяется новый участник. Поначалу он только наблюдает и вникает в основные концепции, проиллюстрированные опытным коллегой. И лишь затем берет самостоятельные задачи и пытается воспроизвести усвоенное ранее. Безусловно это не отменяет наличия подробной документации, к которой можно будет обращаться позже. Такое упражнение поможет новичку разобраться в основах кодовой базы компании, особенно если продукт достаточно сложен или разрабатывается/поддерживается много лет подряд.
Отладочные сеансы. Все мы знаем, что это такое и в каких сценариях они могут происходить. В этом контексте парное программирование подходит как нельзя лучше, так как обеспечивает мгновенную обратную связь. Два инженера пытаются отследить одну и ту же ошибку и найти работающее решение. Это весьма свободный сценарий, поэтому роли ведущего и наблюдателя могут быстро сменяться в пинг-понг режиме.
Решение сложных задач. Сложность в программировании может быть очень относительной вещью. Одни склонны к чрезмерному усложнению, другие — к упрощению задач. В любом случае, иногда может понадобится другой человек, который посмотрит на то, что вы делаете, и поможет выйти из затруднительного положения. Возможно, ему будет достаточно указать на нюансы, которые вы пропустили, или помочь с некоторыми специфическими затруднениями. В подобных ситуациях я принимал участие неоднократно. Инженеры зарывались в яму, а в ходе короткого сеанса парного программирования понимали, что решение на самом деле лежало на поверхности. Подведение их к этому решению было для меня отличным опытом. И этот аспект я решил выделить в отдельный пункт.
Преподавание или обучение. В мире разработки программного обеспечения просто невозможно знать все. Остерегайтесь программистов, которые утверждают, что у них есть ответы на все вопросы, и что им больше нечему учиться. Парное программирование может здорово помочь вам передать знания менее опытному коллеге или наоборот освоить ранее незнакомые фишки и подходы. В медицине это распространено повсеместно. Хирурги, например, перенимают новые методы у коллег, которые уже освоили их. Возможно, у вас периодически возникают проблемы с промисами в JavaScript? В таком случае вам стоит поискать коллегу, который умеет с ними обращаться, и предложить ему сеанс ПП.
Возможно, есть и другие сценарии, в которых парное программирование может оказаться полезным. Но, думаю, суть вы уловили: не нужно возводить парное программирование в культ и прибегать к нему по любому поводу. Это всего лишь инструмент – и строить вокруг него корпоративную культуру было бы крайне неосмотрительно.
Для чего не подходит парное программирование
Теперь рассмотрим ситуации, когда парное программирование не приводит к положительным результатам, и на то есть веские причины. Как я уже говорил (и не устану повторять!), парное программирование – это не панацея и не серебряная пуля. Это всего лишь инструмент, который, если применять его бездумно, может принести больше вреда, чем пользы.
Самая распространенная проблема, с которой сталкиваются команды разработчиков программного обеспечения, — это отсутствие документации. Ее либо вообще нет, либо она устарела. И это оказывает заметное влияние на качество работы. Некоторые (и даже многие) считают, что парное программирование — отличная альтернатива для плохой или отсутствующей документации. Но полагаться на “сарафанное радио” как на источник знаний для новых инженеров или команд просто недопустимо!
Замена документации парным программированием — невероятно расточительное и неэффективное решение. Никоим образом не опускайтесь до такого уровня.
Помимо этого, парное программирование не стоит применять при любом затруднении у младших коллег. Иначе многие из них начнут полагаться на него до такой степени, что просто потеряют способность писать код или в принципе самостоятельно решать задачи. Это очень опасно и в перспективе может сильно навредить их дальнейшей карьере. Единственный способ достичь высокого уровня в разработке программного обеспечения — обрести независимость. Под этим подразумевается способность охватить задачу в целом и находить решения самостоятельно, без посторонней помощи.
И, наконец, рабочее время не стоит переводить на пустую болтовню. Звучит смешно? Но это на самом деле проблема. Когда два человека в команде работают над одним и тем же кодом, они не только совместно решают поставленную задачу, но и неизбежно начинают общаться на отвлеченные темы. Когда на пустые разговоры уходит столько же времени, сколько на решение самой задачи, возникает новая проблема — трата полезных ресурсов. Теперь стоимость разработки даже не удваивается, а утраивается и учетверяется. Сессии парного программирования требуют высокой дисциплины, акцент должен оставаться на решении проблемы. Обмениваться любезностями, конечно, всегда приятно, но тут на кону стоят реальные деньги компании.
Последние аргументы
Вместо классического абзаца с заключительными мыслями я решил еще раз расставить все точки над i. Парное программирование – это далеко не новая концепция. Она появилась довольно давно и все еще остается актуальной, несмотря на то, насколько сильно изменился процесс разработки в последние несколько десятилетий. Особую популярность ПП приобрело в 90-е годы. В онлайн-опросе, проведенном в 2000 году, то есть 24 года назад, около 95% опрошенных заявили, что являются поклонниками парного программирования. Однако есть здесь и подвох. Все респонденты так или иначе практиковали парное программирование на работе.
Проведенный в 2009 году метаанализ эффективности парного программирования показал, что «парное программирование не является универсально полезным или эффективным».
Парное программирование вошло в моду задолго до Agile, Web 2.0, Искусственного Интеллекта и современных заумных IDE. То есть, на свете не было большинства инструментов, на которые мы теперь полагаемся при разработке. Технологические компании раньше были совсем другими и функционировали в рамках другого контекста. Конкурентная борьба строилась по иным законам, а скорость разработки была в разы меньше, чем сегодня, когда непрерывные интеграция и доставка стали нормой.
Наконец, есть то, что, кажется, никто не принимает во внимание, продвигая парное программирование как решение всех проблем кодирования, — это личность инженера. Многие старшие инженеры-программисты наотрез отказываются от работы с живым кодом на собеседовании. Но наравне с ними есть и те, кто выступает против парного программирования. Причина одна — они привыкли работать иначе. Это плохо ложится на их характер. Например, как штатный инженер, я будто бы жонглирую множеством тарелок и переключаюсь с одного контекста на другой десятки раз в день.
Часть моей работы заключается в том, чтобы быть в контакте со всеми остальными членами команды, помимо работы над, собственно, кодом. Представьте себе, что я вынужден при этом участвовать в сессиях парного программирования. Мне пришлось бы сосредоточиться только на одном коллеге и игнорировать всех остальных.
Некоторые инженеры любят слушать музыку или подкасты во время работы. Им нравится находиться в собственном «пространстве». Это вовсе не означает, что они асоциальны. Таков их способ достижения результата. Другие склонны часто делать короткие перерывы. Я, например, никогда не покидаю рабочее место просто чтоб размяться, разве что хожу на обед. Каждый день я выделяю время для чтения входящих сообщений, электронной почты, а иногда устраиваю четырехминутный просмотр свежих клипов любимой группы на YouTube. Делать все это во время сессии парного программирования было бы неуважительно и неразумно.
Проще говоря, парное программирование – это не панацея. Это инструмент. Применяйте его с умом и в правильном контексте.
beeline cloud— secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
