Привет. Меня зовут Дима Вдовин. В предыдущей статье я излагал теорию о парном программировании и говорил о том, какие плюсы вижу в этом подходе. Сегодня я бы хотел продолжить эту тему и поговорить о том, как начать практиковать парное программирование у себя в команде. Полный перечень всех плюсов есть в предыдущей статье, а тут мы просто тезисно вспомним, что нам дает парное программирование.

• Обучение и онбординг новичков.
• Шеринг кода/процессов и обмен опытом.
• Пара решает проблему быстрее и реже обращаются за помощью.
• Повышение производительности.
• Сплочение коллектива.
• Увеличение скорости ревью.

Последний пункт стоит пояснить отдельно. Так как при работе в паре процесс ревью, фактически, проходит в фоновом режиме, то и часть ошибок отсеивается еще на этапе написания кода. Благодаря этому итераций на ревью становится значительно меньше. Тут хорошо подходит вот эта картинка:


Но давайте начнем с грустного и поговорим о том, что может помешать начать внедрять парное программирование в своей команде.

Если в двух словах, то это чаще всего это недостаточная «зрелость» команды и влияние некоторых стереотипов. Для себя я выделяю следующие популярные стереотипы и причины, которые мешают начать практику парного программирования:

• Если посадить двух программистов за два разных компьютера, то они напишут в два раза больше кода. Этот стереотип еще имеет форму «девять женщин могут родить ребенка за один месяц».
• Мы же наняли еще одного программиста, значит можем взять на N задач больше в спринт.
• Один я пишу код лучше и быстрее, нежели чем когда кому-то объясняю, что делать и как я это вижу.
• Во время планирования задачи распределяются не на команду, а индивидуально в виде «Петя возьмет таск X, а Коля будет делать таск Y».
• Конфликты в команде.

Но есть и хорошая новость. Парное программирование не нужно внедрять сразу на всю команду.

Для начала стоит опробовать его всего на одной паре разработчиков, которая возьмется за этот эксперимент. Безусловно, вам будет нужен человек, который займется агитацией на эту тему внутри команды, будет предлагать попробовать парное программирование в том или ином виде. Кстати, о возможных парах я писал в предыдущей статье, и это далеко не всегда два кодера. Так вот, если вы найдете пару разработчиков, которые будут готовы послужить примером, то потом по цепочке положительного фидбека эта практика распространится среди других участников команды.

Конечно тут тоже есть свои нюансы.

Первое. Как показывает мой опыт, большинству людей парное с первого раза не заходит. Очень часто со старта у людей, впервые пробующих парное программирование, совсем ничего не получается. И это нормально. Но важно понимать, что парное программирование — это такой же навык, как и любой другой. Десять тысяч часов практики в любом деле — и ты станешь мастером.

Это правило актуально и для парного программирования, потому что тут мы одновременно имеем дело и с написанием кода, и с абсолютно новым типом коммуникации между членами команды. Как итог, чем больше разработчики практикуют парное программирование, тем лучшие результаты оно дает. Плюс сами девелоперы начинают получать удовольствие от совместной работы, больше проникаются этим подходом.

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

Кому-то больше заходит попробовать парное программирование на мелких тасках. Мотивация тут простая: посмотреть что это и как работает, так сказать буквально проникнуться ситуацией работы «плечом к плечу» с коллегой. Ну а кому-то элементарные задачи совсем не заходят.

Некоторых разработчиков буквально выводит из себя необходимость тратить время на совместную работу над простыми тасками и они придерживаются мнения, что такую элементарную работу они бы сделали намного быстрее и качественнее в одиночку. Таким людям, очевидно, лучше зайдет какая-то большая и сложная задача, где надо крепко подумать над разработкой подхода и архитектуры. В такой ситуации они смогут увидеть преимущества парного программирования во всей красе и понять, что вдвоем верное решение можно найти действительно быстрее.

Если вы решили все же попробовать парное программирование в своей команде, то вот вам пару советов и наблюдений, с чего лучше начать:

• Следите за тем, чтобы девелоперы менялись местами. Смена ролей помогает держать людей в тонусе и погруженными в процесс решения задачи.
• Не рекомендую делать очень длинные сессии, причем как в одной роли, так и сессию парного программирования целиком. Сама сессия парного программирования отнимает достаточно много сил и ресурсов человека. Находиться в ней очень долго тяжело, особенно если вы только начинаете внедрять эту практику в команде. На мой взгляд, на старте вся сессия не должна превышать нескольких часов.
• Не стоит пытаться писать в паре каждый день и хвататься при этом за любые задачи спринта. Лучше заранее определить, на каких тасках вы попробуете метод парного программирования. Это может быть всего несколько задач из целей спринта. Как подобрать эти задачи я писал выше — это зависит от самих разработчиков.
• Не стоит формировать пары случайным образом. К этому вопросу надо подойти с ответственностью. По моему опыту, хорошо срабатываются пары со схожим темпом работы. Также хорошо показывают себя люди, которые давно работают вместе и хорошо знают друг друга. Ну и конечно же, если посадить за парное программирование человека, который не хочет этим заниматься, то ничего не получится.
• Внутри команды/компании должен существовать четкий code style и согласованные подходы к разработке. Это нужно, чтобы во время сессии парного программирования разработчики не тратили время на споры о том, как должен быть оформлен код и как его вообще стоит писать.

Теория это хорошо, но как это реализовать физически?

Во времена до пандемии с реализацией практики парного программирования было проще. Два разработчика садились за один стол или шли в переговорку с большим монитором или телевизором, а в процессе работы просто передавали друг другу ноутбук/клавиатуру. И я не просто так упомянул телевизор.

Главное условие организации процесса парного программирования — возможность свободно читать код для обоих участников пары. Именно поэтому я кроме большого монитора предлагаю рассмотреть вариант с использованием телевизора, чтобы штурман не сидел боком или не заглядывал драйверу через плечо. Ведь личное пространство никто не отменял.


На этом фото сессия моб-программирования, в которой я участвовал еще в докарантинные времена. Как видите, все чувствуют себя комфортно и не сидят друг у друга на головах :)

Сейчас же, с приходом массовой удаленной работы, просто сесть рядом стало проблематично, но желание продолжать практиковать парное программирование оказалось сильнее. Не могу сказать, что я видел и пробовал очень много решений для организации парного программирования онлайн, но из того, с чем имел дело, ничего конкретного порекомендовать не могу. Тут надо отметить, что мы в команде используем стек kotlin/java + JS/TS и используем продукты от JetBrains. И вот путей удобной организации парного программирования с использованием их продуктов я не нашел. Поэтому вначале мы использовали пусть и не самый удобный, но простой способ — созвон через Zoom. Драйвер шарил свой экран, штурман мог видеть, что пишет драйвер, и комментировать это в процессе.

Стоит сделать оговорку, что управление чужой машиной через Zoom у нас запрещено службой безопасности. Это ограничение приводило в процессе к ряду неудобств. Конкретно — без удаленного управления сложно делать частые смены ролей. По этой причине мы начали декомпозировать задачи на более мелкие, чтобы ее можно было выполнить за одну сессию в роли драйвера, а менялись ролями уже при переходе от одной задачи к другой.

Проблема такого подхода в том, что разбить задачу на мелкие части не всегда возможно. Из-за этого иногда приходилось пребывать в одной роли достаточно долго.

Иногда мы поступали иначе: драйвер делает коммит в новую ветку того, что успел написать. Мы ставили статус WIP этому коммиту (Work in progress) и после смены ролей новый драйвер пулил эту ветку и продолжал писать код. Такой вариант тоже не очень хорош, так как появлялось слишком много коммитов, которые, по сути, были не работающими. Конечно, потом можно было бы их сквошить, но все равно — подход так себе.

В целом же, если у вас нет ограничений на использование софта с функцией демонстрации и удаленного управления экраном, то вы с подобными проблемами не столкнетесь и сможете меняться ролями с той частотой, с которой вам будет нужно.

В итоге мы пришли к новому продукту JetBrains, который они выпустили в бета-тест. Речь об инструменте для совместного программирования «Code with me». Он позволяет устраивать удаленные сессия парного программирования с совершенно новым уровнем комфорта. Несколько пользователей одновременно может писать в разных местах одного файла или в разных файлах, либо «синхронизировать» свои фокусы ввода. Плюс вы нормально видите «дерево» всего проекта, все его классы и файлы — это очень полезно и помогает в работе. Если интересно, то посмотреть можно тут.

Конечно, для других инструментов тоже есть подобные решения. Я видел что-то похожее для Atom, Visual Studio и других. Но так как мы пользуемся продуктами JetBrains, то что-то конкретное я могу сказать только про них. Если вы пользовались решениями, похожими по описанию на «Code with me» — поделитесь в комментариях.

Вместо морали

Я считаю, что самое главное — это не нужно заставлять людей практиковать парное программирование, они должны прийти к этому самостоятельно. Только так разработчики смогут почувствовать плюсы и выгоды этого метода. Также надо признать, что не каждый может работать в паре, либо пару разработчику тяжело найти. Так бывает и это нормально. Люди, задействованные в парном программировании, должны «подходить» друг другу.