Не так давно я поинтересовался у коллег по команде, может ли разработчик находиться в потоке, программируя в паре. Ответ по-настоящему меня удивил. Дело в том, что сам я занимаюсь разработками ПО на протяжении 20 лет и в большинстве своем индивидуально. Во время работы я часто пребываю в потоковом состоянии, означающим глубокое сосредоточение и внимание на задаче, которое позволяет отгородиться от мира и достигать невероятных успехов.
Не поймите меня превратно — большую часть карьеры я работал в команде. Просто до недавнего проекта я никогда не практиковал парные разработки. Более того, должен признаться, что я не принимал такой подход, предпочитая программировать самостоятельно. Мне казалось, что, только работая независимо, я смогу достичь состояния потока, а парное программирование — не что иное, как изнурительный труд, истощающий и требующий больше времени.
Но, по мнению первого же опрошенного коллеги, данная техника не только позволяет достичь потокового состояния, но усиливает и углубляет его.
Я был шокирован. Мне и в голову не могло прийти, что кто-то действительно любит программировать таким образом, да еще и умудряется делать это продуктивно. И вообще не понятно, зачем платить двум специалистам за один и тот же объем кода?
В интернет-пространстве многие блогеры и разработчики уже не раз обосновывали свои “за” и “против” парного программирования. В данной статье я не буду агитировать ни за принятие, ни за отказ от этой концепции.
Я лишь предложу альтернативные варианты программирования в парах на случай, если эта техника не дает вам покоя.
Правда в том, что все люди разные: кто-то в восторге от парных разработок, а кто-то нет. А в командах присутствуют как первые, так и вторые. Вопрос в том, как максимально эффективно использовать потенциал каждого разработчика. Парное программирование — всего лишь один из имеющихся инструментов, который в зависимости от способа применения помогает либо повысить продуктивность работы, либо ее снизить.
Почему нам не обойтись без парного программирования?
Данная техника существует уже долгое время. Аналогично экстремальному программированию (XP) ряд гибких методологий разработки настоятельно рекомендуют программировать в парах. Суть в том, что эффективность взаимодействия двух разработчиков по крайней мере не ниже, чем при индивидуальной работе, а вот качество кода при этом становится лучше.
Идея была подхвачена и получила дальнейшее развитие — так появились вариации коллективного программирования, которые подразумевают участие двух и более программистов в работе над одним и тем же кодом.
Если только вам не посчастливилось приобрести собственную компанию, обзавестись успешным индивидуальным продуктом и заниматься единоличными разработками, то, скорее всего, вы работаете в команде. На протяжении своей карьеры, будучи вовлеченным в командные проекты, я программировал отдельно от кого-либо, но сам того не замечая, участвовал в парном программировании. Потому что всегда были случаи, когда я заходил в тупик при решении задачи или нуждался в обратной связи при рефакторинге. Теперь же осмысляя опыт фактического парного программирования, не могу не заметить схожие черты. Таким образом, даже если вы программируете самостоятельно, вам придется взаимодействовать с другими разработчиками ради решения задач.
Инструменты и техники
Итак, согласно классическому подходу парного программирования два разработчика сидят за одной клавиатурой. В число традиционных техник входят следующие.
- Водитель (опытный) + штурман (опытный).
- Пинг-понг.
- Директивный стиль (strong style): штурман (опытный) + водитель (новичок).
- Возможны и другие.
Не будем детально рассматривать принципы и преимущества/недостатки этих методов, поскольку они сопровождаются полноценной документацией. Отметим лишь, что в большинстве случаев парное программирование строится на основе модели “водитель-штурман”. Это относится и к двум остальным техникам из вышеприведенного списка.
Итак, вы не верите, что сможете достигнуть состояния потока, программируя с кем-то в паре, но ваша команда настаивает именно на этом. Что же делать?
В этом случае разумно внести определенные коррективы, обеспечивающие больше простора для индивидуальной работы. Вы можете просто добиться сокращения времени, выделяемого на ежедневное парное взаимодействие. В зависимости от позиций команды или руководства вам удастся это сделать с меньшим или большим успехом. Вы можете предложить альтернативные варианты парной работы, описанные ниже. Главное — позволить разработчикам погружаться в поток индивидуально (если это именно то, что им нужно), а команде — извлекать все преимущества парного программирования.
Примечание. Предлагаемые ниже техники обусловлены моим личным опытом и верой в то, что они сделают процесс парного программирования более приятным и менее утомительным, особенно для интровертов. Они не подкреплены ни научными данными, ни статистикой, ни двойными слепыми методами тестирования.
Такие традиционные техники, как “водитель-штурман”, “пинг-понг” или “директивный стиль”, предполагают чрезмерное общение, ежедневное участие в котором является настоящим испытанием для интровертов.
Такие люди черпают энергию, обдумывая решение задач наедине с самими собой, а не в процессе динамического мозгового штурма. Далее я поделюсь идеями по поводу более подходящих техник парного программирования для интровертов.
Важно отметить, что пандемия и удаленная работа способствовали внедрению этих техник. Если раньше парное программирование осуществлялось при непосредственном взаимодействии разработчиков за одним компьютером и клавиатурой, то сейчас, подобно другим видам деятельности, оно перешло на дистанционный формат. Программисты работают за своими собственными машинами, в связи с чем становится возможным опробовать альтернативные подходы как дистанционно, так и при личной встрече (с соблюдением социальной дистанции).
VS Code Live Share — это простейший способ организации совместной деятельности. Пары используют два компьютера, работая над одним и тем же кодом с помощью Live Share. При этом не важно, где вы в этот момент находитесь: удаленно или в одном офисе. Если вы еще не знакомы с Live Share, то настоятельно рекомендую это исправить. Данный инструмент позволяет одному разработчику запустить сеанс и пригласить коллег к нему присоединиться. Организатор сеанса определяет правомочия гостей. Оба разработчика могут редактировать и сохранять код, а также выполнять команды в терминале и проводить тестирование.
Суть в том, чтобы максимально выгодно применять преимущества парного программирования, уважая при этом социальные потребности интровертов и способствуя повышению их продуктивности.
Оставим старые традиционные подходы экстравертам и ниже рассмотрим возможные варианты парного программирования для интровертов.
1. Разделяй и властвуй
Для реализации данной техники требуется наличие пользовательской истории, допускающей беспроблемное разделение по крайней мере на две части. В зависимости от способа ее написания и владельца продукта это может оказаться не так-то просто. При таком подходе разработчики совместно участвуют в создании одной пользовательской истории, но отвечают за разные ее части. В идеале хорошая история должна включать изменения, связанные как с фронтендом, так и с бэкендом. Одни команды следует этому принципу, а вот другие пишут истории, ограниченные либо в одном, либо в другом.
Сначала пара разработчиков делит объем работы, после чего какое-то время выделяется на самостоятельное решение поставленных задач. Они могут договориться о продолжительности выполнения индивидуальных заданий или определять его по методу “помидора”. На следующем этапе разработчики оценивают достигнутые результаты, проводят обоюдное ревью кода и определяют места интеграции, в которых их код совмещается. После этого процесс повторяется заново до момента завершения работы над историей.
2. Показывай и рассказывай
Этот формат деловых взаимоотношений похож на предыдущий, за исключением того, что оба специалиста участвуют в разработке двух различных, возможно, даже не связанных друг с другом пользовательских историй. Работая обособленно, я предпочитаю сначала обдумать решения задач, а затем выгодно их представить. В дальнейшем обосновывая и объясняя принципы работы кода, и сам начинаешь лучше его понимать.
Данная техника предполагает следующую последовательность действий. Сначала происходит разбор историй, предназначенных для разработки, и устанавливается продолжительность индивидуальной работы (как и в предыдущем случае). Здесь временные рамки могут быть шире, поскольку задачи каждого из программистов не зависят друг от друга. На следующей встрече специалисты поясняют и показывают друг другу реализацию и модульные тесты. Они обсуждают возникающие проблемы и ищут наилучшие решения. В таком ключе все повторяется вплоть до завершения работы над обеими историями.
3. Кому — код писать, а кому-то — его тестировать
Приверженцы канонов разработки через тестирование (TDD) наверняка поднимут меня на смех за следующую технику, но все-таки я рискну. Она предполагает совместную парную работу над одной пользовательской историей. Один разработчик пишет код, а другой его тестирует. Предварительно происходит разбор истории и определяются основные структуры данных (например, используемые классы, модули, функции или компоненты). По ходу могут создаваться интерфейсы или структуры данных, упрощающие индивидуальную работу.
По завершении предварительного этапа обговариваются временные рамки. Автор кода работает над реализацией функциональности, а тестировщик ищет всевозможные способы нарушить ее работоспособность. В процессе индивидуальной работы это можно выразить в виде псевдокода модульного теста. Более подробное предварительное обсуждение способствует созданию более точного псевдокода. По истечении установленного времени разработчики сходятся и преобразуют этот псевдокод в фактические модульные тесты, в случае прохождения которых работа над историей завершается.
Заключение
Парное программирование постепенно становится обычной практикой многих команд разработки ПО. Экстравертам больше подходит традиционная техника “водитель-штурман”. Те, кто приветствует такой подход к программированию, могут погружаться в “поток”, объединяясь с одним или большим числом коллег для работы над задачей. Интровертам же нужно нечто иное для достижения потокового состояния.
В связи с этим, надеюсь, что предложенные техники, во-первых, помогут им в этом, а, во-вторых, повысят чувство удовлетворения от работы, сохраняя при этом все преимущества рассмотренного подхода.
Сможете ли вы попасть в поток в процессе парного программирования — зависит от вас. У каждого разработчика команды разные потребности и способы повышения персональной продуктивности и получения удовлетворения от выполняемых заданий. Не бойтесь их сочетать, и результаты не заставят себя ждать!
Читайте также:
- Как программирование избавляет от стресса
- Почему большинство инженеров ПО не пишут документацию?
- 10 бесплатных ресурсов для обучения обработке естественного языка
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Ezra Bowman: How To Achieve Flow While Pair Programming
