Привет, Хабр! Сегодня поговорим о парном программировании, с передачей опыта Сбера — наши разработчики знают о методике парной работы не понаслышке. Команда программистов становится командой только при постоянном взаимодействии. Если один кодит, а другой просто смотрит — это просто наблюдение, а не парное программирование. Как же заниматься этим правильно? Подробности под катом.
Это как игра, только работа
Да, в парном программировании есть формальные правила, как в игре. Но они используются для того, чтобы работа была быстрой и эффективной. Что касается участников процесса, то их обычно двое. Может быть и больше, но об этом расскажем ниже. Эти двое получают соответствующие роли:
Ведущий — тот, кто работает на клавиатуре в текущий момент. Он сосредотачивается на задачах, которые необходимо решить в первую очередь. Перед началом работы ведущий обсуждает общее направление работы с напарником.
Штурман (напарник) — он смотрит, что именно пишет ведущий, комментирует его действия (не нудит, конечно, а делает конструктивные замечания — в идеале) и направляет общий ход идей и мыслей. Штурман занят проработкой общей стратегии, а также проверяет код на ошибки. Фактически, проводит code review в реальном времени.
Участники процесса меняются ролями раз в полчаса, час или реже — всё зависит от опыта работы в паре, навыков, самой задачи и других нюансов. Навыки и опыт могут быть разными. В таком случае штурман может взять на себя не только стратегию, но и тактику. Соответственно, в процессе работы ведущий ещё и обучается.
Как появилось парное программирование?
В общем-то, идея не нова. Ведь часто люди, работая в паре, дают друг другу советы, заменяют коллегу, когда тот устал, делятся опытом и т. п. Это практикуется тысячелетиями во множестве профессий. Вспомните школу: иногда домашку делали с другом или подругой, и приёмы работы были похожи на парное программирование. С той разницей, что оба участника процесса и ведущий и штурман одновременно.
Но осмысленно такой подход в программировании был применён учёным и разработчиком из Нидерландов Эдсгером Дейкстра. Несколько десятилетий назад он вместе со своим коллегой работал над компилятором для Algol 60, и для ускорения работы программисты стали использовать парное программирование. Они записывали каждую инструкцию в компиляторе только после совместного её обсуждения. Работать получалось эффективнее благодаря тому, что ошибок стало меньше. Правда, были не только ошибки написания кода, но и так называемые «ошибки мышления». В этом случае если один программист видел ошибочность рассуждений второго, он старался рассказать тому об этом. Иногда это была действительно ошибка, и от неё избавлялись. А иногда всё было верно и автору идеи удавалось её отстоять.
Окончательно концепцию парного программирования сформулировал Кент Бек. Он создал методологию экстремального программирования, частью которой стало парное программирование. Произошло это в 1994 году, когда Бек работал над проектом Chrysler Comprehensive Compensation System. Он взял уже зарекомендовавшие себя практики и довёл их до максимальной эффективности. Кроме парного программирования в методологию входило также модульное тестирование, принцип YAGNI и другие. Сейчас различные модули методологии экстремального программирования используются весьма активно. Некоторые, например модульное тестирование, популярнее и востребованнее других. Но и парное программирование достаточно актуально.
Кстати, есть разновидность коллективного программирования, когда код одного проекта пишет не два человека, а три или даже больше. Это, конечно, уже экзотика, но такое тоже случается. В этом случае один сотрудник набирает код, а все остальные — штурманы. В некоторых случаях такой метод себя оправдывает и не приводит к хаосу в команде. Хотя, конечно, использовать такую практику достаточно сложно, особенно для неподготовленных разработчиков.
Что даёт парное программирование?
Многое, но применять его нужно с оглядкой на команду и компанию, внутри которой ведётся работа. Эффективность парного программирования подтверждает научное исследование, в рамках которого проводились эксперименты с результативностью разработчиков. В исследовании принимали участие 15 программистов. Из добровольцев сформировали 5 пар и оставили 5 одиночек. Всем была поставлена одна и та же задача. При этом пары в среднем выполнили свою задачу на 12 минут быстрее одиночек, создав, к тому же, более читаемый и работоспособный код.
Преимуществ у парного программирования больше, чем недостатков. Среди плюсов:
Повышение качества кода и ускорение рефакторинга. Если работа организована рационально, то пара разработчиков создаёт качественный код с минимумом проблем.
Оптимальное количество строк в коде. Работая в паре и постоянно рефакторя код, разработчикам удаётся сократить количество строк, убирая всё ненужное.
Снижение количества багов. Это ещё одно следствие постоянного рефакторинга, выполняемого штурманом во время работы. В чужом коде, зачастую, баг разглядеть проще, чем в своём. Соответственно, штурман замечает большую часть проблем, а ведущий их исправляет.
Обучение. Даже если оба разработчика примерно равны по опыту, у каждого есть свои ноу-хау, которыми они обмениваются в работе.
Развитие навыка работы в команде. Именно при парном программировании можно максимально прокачать навык командной работы.
Повышение сосредоточенности на работе. Работая в паре, программисты реже отвлекаются, в том числе, и на кофе с обсуждением чего бы то ни было с коллегами. Да и прокрастинировать в связке достаточно сложно.
Парное программирование в Сбере
Оно применяется в наших командах, но не так, чтобы очень уж часто. Опытом работы с парным программированием попросили поделиться …. Вот их ответы и мнение; надеемся, будет полезно для читателей. Тут одновременно можно узнать и о нюансах работы в парах, и о недостатках самой концепции. Применять её везде и всюду уж точно не стоит.
Часто ли вы практикуете парное программирование?
От случая к случаю. Эта методика эффективна для ограниченного набора ситуаций и типов задач, а также в течение ограниченного времени. Поначалу разработчикам это бывает интересно, но со временем штурман на соседнем кресле начинает только раздражать. Представьте, что вы за рулём автомобиля, а пассажир постоянно даёт вам советы как ехать, хотя вы и без него это знаете. Но, конечно, есть и случаи, когда работа идёт гладко и без проблем.
Когда парное программирование оправдано, необходимо, а когда его лучше не вводить?
Оно действительно полезно, если нужно передать знание кодовой базы новому разработчику. В этом случае обучаемый самостоятельно делает задачу, а штурман подсказывает наилучший способ решения возникающих проблем, попутно делясь знаниями о системе. При этом обучаемый должен быть уже опытным разработчиком, иначе штурман очень сильно заскучает, следя за медлительным коллегой.
Вопроса вводить или не вводить парное программирование стоять не должно. Можно только предложить, а разработчики должны решить сами, нужно ли им это. В большинстве случаев для достижения желаемого результата может оказаться достаточно ввести обязательную проверку кода, а не наблюдение всего процесса разработки.
Что вам даёт такой способ работы, есть ли положительные моменты? Если да, то какие?
Это сплачивает команду (в тех случаях, когда не разрушает), повышает отдачу ведущего, помогает делиться опытом. В условиях удалённой работы наши сессии парного программирования часто превращались в способ общения команды. Когда мы в последний раз применяли эту методику, помимо двух непосредственных участников к нам на созвон заходили джуны, чтобы понаблюдать мастер-класс, забегали девопсы, чтобы задать какой-то вопрос, приходили пообщаться аналитики, которым, кажется, просто было одиноко.
Какие недостатки вы заметили в таком способе работы?
Если не стоит задачи обмена опытом и оба разработчика хорошо знакомы с системой, то пока работает один, другой, скорее всего, не работает. Это неэффективно. Бывают и психологические барьеры: не все готовы по шесть часов в день (обычно столько получается) общаться с другим человеком. Но, снова повторю, всё это индивидуальный опыт; уверен, есть и другие примеры.
Насколько они критичны для общего процесса?
Парное программирование, будучи не к месту или насильно внедрённым в процесс, может негативно сказываться на эффективности и мотивации команды, вызывать текучку кадров. Поэтому оно должно применяться добровольно и ситуативно. Это не универсальный инструмент.
Что вы можете посоветовать коллегам, которые планируют ввести парную систему работы?
Не переходить на неё целиком, а работать по этой методике только над конкретными задачами. И универсальный совет — проводите ретроспективы, обсуждайте результаты.
Поделитесь своим опытом парного программирования, если он у вас есть. Всем нам будет интересно узнать как об успехах, так и неудачах работы в командах парного программирования.
