Последний пункт стоит пояснить отдельно. Так как при работе в паре процесс ревью, фактически, проходит в фоновом режиме, то и часть ошибок отсеивается еще на этапе написания кода. Благодаря этому итераций на ревью становится значительно меньше. Тут хорошо подходит вот эта картинка:
Но давайте начнем с грустного и поговорим о том, что может помешать начать внедрять парное программирование в своей команде.
Если в двух словах, то это чаще всего это недостаточная «зрелость» команды и влияние некоторых стереотипов. Для себя я выделяю следующие популярные стереотипы и причины, которые мешают начать практику парного программирования:
Но есть и хорошая новость. Парное программирование не нужно внедрять сразу на всю команду.
Для начала стоит опробовать его всего на одной паре разработчиков, которая возьмется за этот эксперимент. Безусловно, вам будет нужен человек, который займется агитацией на эту тему внутри команды, будет предлагать попробовать парное программирование в том или ином виде. Кстати, о возможных парах я писал в предыдущей статье, и это далеко не всегда два кодера. Так вот, если вы найдете пару разработчиков, которые будут готовы послужить примером, то потом по цепочке положительного фидбека эта практика распространится среди других участников команды.
Конечно тут тоже есть свои нюансы.
Первое. Как показывает мой опыт, большинству людей парное с первого раза не заходит. Очень часто со старта у людей, впервые пробующих парное программирование, совсем ничего не получается. И это нормально. Но важно понимать, что парное программирование — это такой же навык, как и любой другой. Десять тысяч часов практики в любом деле — и ты станешь мастером.
Это правило актуально и для парного программирования, потому что тут мы одновременно имеем дело и с написанием кода, и с абсолютно новым типом коммуникации между членами команды. Как итог, чем больше разработчики практикуют парное программирование, тем лучшие результаты оно дает. Плюс сами девелоперы начинают получать удовольствие от совместной работы, больше проникаются этим подходом.
Второе. Крайне важны задачи, с которых наши разработчики начнут практиковать парное программирование. И вот тут у меня, к сожалению, нет однозначных рекомендаций. Какие-то пары идеально раскрываются при работе над ультра-хардкорными задачами, а каким-то разработчикам нужно поэтапно двигаться от элементарных тасков к более сложным.
Кому-то больше заходит попробовать парное программирование на мелких тасках. Мотивация тут простая: посмотреть что это и как работает, так сказать буквально проникнуться ситуацией работы «плечом к плечу» с коллегой. Ну а кому-то элементарные задачи совсем не заходят.
Некоторых разработчиков буквально выводит из себя необходимость тратить время на совместную работу над простыми тасками и они придерживаются мнения, что такую элементарную работу они бы сделали намного быстрее и качественнее в одиночку. Таким людям, очевидно, лучше зайдет какая-то большая и сложная задача, где надо крепко подумать над разработкой подхода и архитектуры. В такой ситуации они смогут увидеть преимущества парного программирования во всей красе и понять, что вдвоем верное решение можно найти действительно быстрее.
Во времена до пандемии с реализацией практики парного программирования было проще. Два разработчика садились за один стол или шли в переговорку с большим монитором или телевизором, а в процессе работы просто передавали друг другу ноутбук/клавиатуру. И я не просто так упомянул телевизор.
Главное условие организации процесса парного программирования — возможность свободно читать код для обоих участников пары. Именно поэтому я кроме большого монитора предлагаю рассмотреть вариант с использованием телевизора, чтобы штурман не сидел боком или не заглядывал драйверу через плечо. Ведь личное пространство никто не отменял.
На этом фото сессия моб-программирования, в которой я участвовал еще в докарантинные времена. Как видите, все чувствуют себя комфортно и не сидят друг у друга на головах 🙂
Сейчас же, с приходом массовой удаленной работы, просто сесть рядом стало проблематично, но желание продолжать практиковать парное программирование оказалось сильнее. Не могу сказать, что я видел и пробовал очень много решений для организации парного программирования онлайн, но из того, с чем имел дело, ничего конкретного порекомендовать не могу. Тут надо отметить, что мы в команде используем стек kotlin/java + JS/TS и используем продукты от JetBrains. И вот путей удобной организации парного программирования с использованием их продуктов я не нашел. Поэтому вначале мы использовали пусть и не самый удобный, но простой способ — созвон через Zoom. Драйвер шарил свой экран, штурман мог видеть, что пишет драйвер, и комментировать это в процессе.
Стоит сделать оговорку, что управление чужой машиной через Zoom у нас запрещено службой безопасности. Это ограничение проводило в процессе к ряду неудобств. Конкретно — без удаленного управления сложно делать частые смены ролей. По этой причине мы начали декомпозировать задачи на более мелкие, чтобы ее можно было выполнить за одну сессию в роли драйвера, а менялись ролями уже при переходе от одной задачи к другой.
Проблема такого подхода в том, что разбить задачу на мелкие части не всегда возможно. Из-за этого иногда приходилось пребывать в одной роли достаточно долго.
Иногда мы поступали иначе: драйвер делает коммит в новую ветку того, что успел написать. Мы ставили статус WIP этому коммиту (Work in progress) и после смены ролей новый драйвер пулил эту ветку и продолжал писать код. Такой вариант тоже не очень хорош, так как появлялось слишком много коммитов, которые, по сути, были не работающими. Конечно, потом можно было бы их сквошить, но все равно — подход так себе.
В целом же, если у вас нет ограничений на использование софта с функцией демонстрации и удаленного управления экраном, то вы с подобными проблемами не столкнетесь и сможете меняться ролями с той частотой, с которой вам будет нужно.
В итоге мы пришли к новому продукту JetBrains, который они выпустили в бета-тест. Речь об инструменте для совместного программирования «Code with me». Он позволяет устраивать удаленные сессия парного программирования с совершенно новым уровнем комфорта. Несколько пользователей одновременно может писать в разных местах одного файла или в разных файлах, либо «синхронизировать» свои фокусы ввода. Плюс вы нормально видите «дерево» всего проекта, все его классы и файлы — это очень полезно и помогает в работе. Если интересно, то посмотреть можно тут.
Конечно, для других инструментов тоже есть подобные решения. Я видел что-то похожее для Atom, Visual Studio и других. Но так как мы пользуемся продуктами JetBrains, то что-то конкретное я могу сказать только про них. Если вы пользовались решениями, похожими по описанию на «Code with me» — поделитесь в комментариях.
Я считаю, что самое главное — это не нужно заставлять людей практиковать парное программирование, они должны прийти к этому самостоятельно. Только так разработчики смогут почувствовать плюсы и выгоды этого метода. Также надо признать, что не каждый может работать в паре, либо пару разработчику тяжело найти. Так бывает и это нормально. Люди, задействованные в парном программировании, должны «подходить» друг другу.
Apple возобновила переговоры с OpenAI о возможности внедрения ИИ-технологий в iOS 18, на основе данной операционной системы будут работать новые…
Конкурсный управляющий российской «дочки» Google подготовил 23 иска к участникам рекламного рынка. Общая сумма исков составляет 16 млрд рублей –…
Google завершил обновление основного алгоритма March 2024 Core Update. Раскатка обновлений была завершена 19 апреля, но сообщил об этом поисковик…
У частных продавцов на Авито появилась возможность составлять текст объявлений с помощью нейросети. Новый функционал доступен в категории «Обувь, одежда,…
24 апреля 2024 года в Москве состоялась церемония вручения наград международного конкурса Workspace Digital Awards. В этом году участниками стали…
27 июня Яндекс проведет гик-фестиваль Young Con для студентов и молодых специалистов, которые интересуются технологиями и хотят работать в IT.…