Обзоры кода для парного программирования
Парное программирование может быть эффективным, но можно ли доверять паре проверку собственного кода или это должна делать независимая третья сторона?
Наша компания Appresso Corporation уже более десяти лет использует парное программирование для создания таких продуктов, как DataSpider Servista, промежуточного программного обеспечения предприятия, которое позволяет ИТ-командам интегрировать широкий спектр источников данных без необходимость кодирования.
В этой статье я поделюсь тем, что мы узнали на данный момент. Мы производим несколько корпоративных программных продуктов, поэтому то, что мы испытали и узнали, может быть неприменимым непосредственно к вашей ситуации, но, надеюсь, это подтолкнет вас к некоторым идеям.
Во-первых, для тех, кто не знаком с этим подходом, позвольте мне дать определение.
Что такое парное программирование?
Парное программирование — это метод гибкой разработки программного обеспечения. Наиболее распространен сценарий, в котором два программиста сидят и работают вместе за одним компьютером. Однако некоторые делают это дистанционно. Мы сделали это лично, так что это сценарий, который я буду описывать.
Есть две роли:
- Драйвер. Это тот, кто занимается практическим написанием кода.
- Навигатор. Иногда его также называют «Наблюдатель», который просматривает каждую строку кода по мере ее ввода.
Идея состоит в том, что во время обзора навигатор должен направлять все в правильном направлении, придумывая идеи для улучшений и предвидя будущие проблемы. Это позволяет водителю сосредоточиться на тактических аспектах выполнения поставленной задачи. Таким образом, навигатор служит и подстраховкой, и проводником. Два программиста часто меняются ролями.
Прежде чем мы перейдем к рассмотрению кода, которому посвящена эта статья, позвольте мне сначала поделиться тем, что мы узнали из нашего опыта парного программирования.
Что мы обнаружили
Это утомительно
При парном программировании Водитель постоянно кодирует под наблюдением Навигатора. Когда я работал водителем, у меня даже не было времени заглянуть в уведомления на телефоне. Даже во время компиляции, когда я обычно мог сделать перерыв, работая в одиночку, мне приходилось использовать время, чтобы объяснять детали и обсуждать следующие шаги с моим навигатором.
Обычно мы работаем над общей задачей с нашим партнером около часа, прежде чем перейти к следующему пункту. Иногда мы делаем перерыв в течение часа, но обычно мы продолжаем работать и делаем десятиминутный перерыв перед тем, как приступить к следующей задаче.
Это интенсивно. Мы отдаем ему все, что у нас есть, и в конце каждого часа чувствуем себя потраченными. Поэтому важно сделать перерыв, чтобы перезарядиться, прежде чем приступить к следующей задаче.
Очевидно, что парное программирование работает только в том случае, если Навигатор четко понимает, что именно делает Водитель, чтобы он мог посоветовать, что делать дальше. Таким образом, Водитель должен постоянно связываться с Навигатором.
Это побуждает к концентрации
При программировании в одиночку сложнее понять, действительно ли вы пишете оптимальный код, спецификации и принимаете правильные дизайнерские решения. Вы несете полную ответственность за свою собственную траекторию, и не всегда легко понять, находитесь ли вы на правильном пути.
Во время парного программирования, как Водитель, зная, что за мной наблюдают, я чувствую себя обязанным написать лучший код, на который я способен. Я гораздо более сосредоточен, потому что не хочу ставить себя в неловкое положение, написав некачественный код.
Это очень весело
Больше всего на свете парное программирование — это весело! Как программисты, мы хотим разрабатывать полезное и качественное программное обеспечение. Если Водитель сбивается с пути или начинает выполнять работу некачественно, Навигатор всегда готов исправить и направить его. Выполнять задачи одну за другой, зная, что вы делаете все возможное, и двигаться в правильном направлении — это очень приятный опыт.
Увлекаюсь парным программированием
Когда большая команда работает с фреймворком Scrum, парное программирование имеет тенденцию происходить естественным образом. Это связано с тем, что даже в течение недельного спринта увеличение незавершенного производства неэффективно.
Например, если шесть программистов одновременно берутся за разные задачи, в конечном итоге они пойдут по разным траекториям. Более простые задачи будут выполнены быстро, а более сложные потребуют больше времени.
Если разработчик берет выходной, ничего не происходит. Чтобы предотвратить эти проблемы, по крайней мере, некоторые члены команды время от времени начинают заниматься парным программированием естественным образом.
Повышенная производительность
Согласно исследованию, представленному в книге Лори Уильямс и Роберта Кесслера Подсветка парного программирования, время разработки увеличивается примерно на 15%.
Другими словами, если что-то нужно сделать самому двадцать часов:
- Парное программирование займет 20*1,15=23 часа.
- Получается 11,5 часов на человека.
- Время на фактическую работу также составит 11,5 часов.
Мы не внимательно отслеживали наше рабочее время для каждой задачи, но моя интуиция подсказывает мне, что это правильно. При парном программировании дела идут быстрее, чем при работе в одиночку. Хотя общее количество затраченных часов увеличивается на 15%, период разработки сокращается.
Улучшенное качество
Парное программирование — отличный способ расширить обмен информацией и улучшить качество кода. В то время как затрачиваемое время увеличивается примерно на 15%, опытный навигатор помогает, находя и указывая на новые вещи по мере продвижения пары, и каждый день приносит новые открытия. Полоса пропускания обмена знаниями увеличивается, а конечный продукт превосходит то, что мог бы создать кодер-одиночка.
Хотя я уверен, что работаю в одиночку, я хорошо справляюсь со своей работой, но поддерживать высокий уровень качества сложнее, а необходимость возвращаться и исправлять проблемы позже — это боль. Напротив, при парном программировании легче поддерживать качество кода, и мы можем продолжать уверенно двигаться вперед.
Это не единственный способ
Я не хочу преувеличивать парное программирование. Хотя у него есть свои достоинства, не ожидайте, что он станет волшебным панацеей, особенно в экстренных ситуациях.
Хотя мы используем парное программирование около десяти лет и обычно находим его продуктивным способом работы, это далеко не единственный подход, который мы используем. На самом деле, если бы мы работали только так, это, вероятно, создало бы различные проблемы.
Парное программирование не всегда удобно. Иногда это просто не соответствует ситуации. Кроме того, не всем разработчикам это нравится, и, возможно, некоторые из них не подходят для этого. Парное программирование следует рассматривать как один из многих подходов, которые может выбрать команда разработчиков.
Хорошо, теперь, когда я подготовил почву, давайте углубимся в основную тему этой статьи.
Парное программирование и код-ревью
Обзор на GitHub Enterprise
Раньше, когда мы использовали Apache Subversion (SVN), коммиттер (рецензент) сидел вместе с рецензентом и проводил их по коду. После того, как обзор был завершен и все проблемы были решены, мы коммитили код.
В настоящее время мы используем GitHub Enterprise и делаем pull request, чтобы инициировать проверку. Запросы на вытягивание позволяют вам сообщать другим об изменениях, которые вы отправили в репозиторий GitHub. После открытия запроса на вытягивание вы можете обсудить и просмотреть возможные изменения с соавторами и добавить последующие коммиты, прежде чем изменения будут объединены в репозиторий. Мы с большим уважением относимся к SVN, но обнаружили, что GitHub Enterprise лучше подходит для нашего текущего стиля работы.
Мы обнаружили, что пулл-реквесты имеют для нас следующие преимущества:
- Можно просматривать асинхронно.
- Контекст обзора остается в качестве комментария.
С другой стороны, мы обнаружили следующие проблемы:
- Как правило, неясно, когда код будет пересмотрен или объединен.
- Большие пулреквесты сложны для рецензента, если им приходится смотреть код с нуля и пытаться во всем разобраться самостоятельно.
Мы решали эти проблемы, прикрепляя документ, объясняющий дизайн кода, заставляя рецензента разговаривать с кодером, а иногда кодировщик и рецензент сидели вместе, чтобы все обсудить.
Наша команда изначально начала парное программирование вместе с внедрением фреймворка Scrum и обнаружила, что это упрощает проверку. Мы не следили должным образом за нашей деятельностью по разработке, но я бы сказал, что в наши дни от 80 до 90 процентов кода, который мы пишем, выполняется с помощью парного программирования. Однако, поскольку мы начали делать это от случая к случаю, мы продолжили работу над запросами на слияние традиционным способом.
Выбор рецензента
Очевидно, что проверку кода должен проводить кто-то другой, а не тот, кто написал код. Однако, как только мы подошли к парному программированию должным образом, возник вопрос: «Было бы более эффективно, если бы пара просматривала свой собственный код?» И «Если мы это сделаем, можем ли мы действительно считать это надлежащей рецензией?»
Мы нашли компромисс: на каждую историю (pull request) у нас было бы два рецензента, одним из которых мог бы быть Навигатор из подавшей пары, но не Водитель.
Короче говоря, мы обнаружили, что это очень эффективно. Поскольку мы писали код в паре, навигатор, участвующий в ревью, его хорошо знает, так что все идет гладко. Сравните это с проверкой неизвестного кода в одиночку, что вызывает стресс и отнимает много времени, потому что вы должны разобраться в коде самостоятельно.
Однако это вызывает вопросы:
- Нужно ли проверять код, написанный парами? И,
- Есть ли смысл в том, чтобы пара просматривала запрос на включение?
Хотя мы можем рассматривать парное программирование как непрерывную проверку, однако, исходя из нашего опыта, необходима отдельная проверка через запрос на вытягивание.
Конечно, в идеале Навигатор должен внимательно направлять Водителя и следовать циклу «красный, зеленый и рефакторинг». Тем не менее, это не всегда так. И Навигатор, и Водитель всего лишь люди. Один из них или оба могут совершать ошибки, которые могут быть пропущены. По этой причине мы обязательно просматриваем код, написанный парами, чтобы мы могли отловить эти пропущенные ошибки.
Сосредоточенность и смелость, поощряемые парным программированием, иногда могут препятствовать полноте или чувствительности.
Вращающиеся пары для обзора
Мы обнаружили, что чередование пар для проверки кода сделало нашу команду сильнее. Со временем каждый член команды ознакомился с каждой частью общего проекта и увидел используемые методологии. Мы смогли не только по-новому взглянуть на каждую деталь, но и распространить ноу-хау по всей команде.
Это означает, что обычно у нас есть от двух до пяти учетных записей пользователей, участвующих в каждом запросе на включение.
Пример запроса на вытягивание с относительно большим количеством участников.
Как правило, мы меняем пары по одному человеку (один человек уходит, а другой остается). Однако мы по-прежнему обнаруживаем, что знания, полученные в результате нашей работы, фрагментарны.
Например, если во время работы Водитель решил вернуться к задаче позже, он может забыть об этом, поменявшись парами, и сосредоточиться на новом наборе задач. Это может привести к пропуску элементов или дублированию кода. Такого рода проблемы можно предотвратить, просмотрев код перед слиянием, поскольку дублирование обычно легко обнаружить.
Соблазнительно думать, что, поскольку код был создан парой, это нормально, однако это может привести к объединению дублированных частей. Всегда лучше уделить время тщательному просмотру кода, чтобы избежать пропущенных ошибок или дубликатов. Обзор также является хорошей возможностью узнать, насколько эффективным было парное программирование и охватывало ли оно все аспекты или нет.
Даже при парном программировании просмотр кода запроса на вытягивание дает хорошую возможность получить целостный взгляд на проделанную работу. Таким образом, по опыту, даже когда большая часть кода написана парой, мы обнаружили, что код-ревью полезен.
Пары просматривают свой собственный код
Я сомневаюсь, достаточно ли сделать запрос на включение и проверку в паре, поскольку они оба были вовлечены в работу и не могут увидеть ее свежим взглядом.
Когда вы пишете код парами, даже если вы были Навигатором, а не Водителем, вы склонны привязываться к работе. Программистам трудно выбрасывать написанный ими код, и это верно и для пар. Вы всегда будете осознавать, что «это код, который я написал».
Однако, когда кто-то другой проверяет, он видит «код, который написал кто-то другой» и может относиться к нему более критически. Они могут попробовать запустить код и внимательно просмотреть каждую строку, проверяя соблюдение стандартов. Таким образом можно сделать десятки комментариев.
Хотя это трудно определить количественно, я думаю, что когда пара просматривает свой собственный код, они упускают такой уровень объективности. По этой причине мы считаем, что всегда лучше, чтобы кто-то, кто не участвовал в процессе написания кода, выполнял проверку.
Как экстремальное программирование влияет на проверку кода
Мы практикуем экстремальное программирование (XP), методологию гибкой разработки программного обеспечения, предназначенную для повышения качества и реагирования на меняющиеся требования клиентов. Он выступает за частые выпуски релизов в короткие циклы разработки, чтобы повысить производительность и ввести контрольные точки, на которых могут быть приняты новые требования клиентов. Одним из элементов этого является парное программирование и обширная проверка кода.
Меняя пары программистов и рецензентов, мы знакомим всех с общей кодовой базой. Они начинают считать весь код своим. Моб-программирование — это когда вся команда работает над одним и тем же, в одно и то же время, в одном пространстве и за одним компьютером — мы делаем это в чем-то, но с временными лагами.
Хорошей стороной этого является то, что у нас есть много мозгов, вовлеченных в процесс написания кода, объединяющих их интеллект. Тем не менее, нам следует подумать о привлечении людей, которые не имеют непосредственного отношения к коду. Если у нас действительно есть ситуация «совместное владение = один мозг», то даже если у нас есть до пяти человек, просматривающих запрос на вытягивание, обзор перестает быть объективным.
Это заставляет меня задаться вопросом, не лучше ли увеличить количество просмотров отзывов, чтобы сделать наш коллективный мозг умнее. Если у нас есть коллективный разум, тогда будут трения между теми, кто непосредственно вовлечен, и теми, кто не участвует.
Возможно, немного трения — это хорошо. Если трение можно классифицировать как проблему кодирования, вероятно, будет более эффективно решать ее в парной работе, а не в асинхронных проверках кода. С другой стороны, если трения приводят к обнаружению ошибок из-за разных точек зрения, то имеет смысл привлечь к процессу проверки «стороннего наблюдателя».
Резюме: помните об эффективности любого подхода
Одна вещь, которую мы узнали за годы пробных различных подходов, заключается в том, что только потому, что код был написан с помощью парного программирования, не дает точного указания на то, оправдана ли проверка. Точно так же из-за ротации команд и того, что у всех развивается чувство полного совладения кодом, это не обязательно означает, что необходимые трения отсутствовали бы, если бы мы проверяли наш собственный код.
Есть много факторов, которые могут действовать как переменные, влияющие на результат, включая навыки и личности участников, а также характеристики продуктов, над которыми они работали. Существует широкий спектр факторов, которые могут изменить состояние команды в любой момент времени.
Чтобы правильно ответить на вопрос «Какой тип проверки кода наиболее эффективен?» вам нужно будет отслеживать эти бесчисленные переменные и анализировать их, чтобы найти тенденции. Это, безусловно, было бы интересным упражнением, которое привело бы ко многим полезным выводам.
Однако без такого анализа сложно дать простой и однозначный ответ на вопрос «А нужно ли пересматривать хотя бы парное программирование?»
Из всего опыта нашей команды с фреймворком Scrum мы не смогли прийти к однозначному выводу о том, нужны ли обзоры при парном программировании. Лучший ответ, который мы можем дать, заключается в том, что это зависит от обстоятельств.
В настоящее время, несмотря на то, что наша команда использует индивидуальный подход, у нас обычно есть пары, которые проводят свои собственные проверки между собой. Однако это может измениться в будущем.
Поэтому я хотел бы завершить эту статью, сказав, что важно осознавать последствия любого подхода к разработке, включая парное программирование. Собирайте как можно больше данных и следите за своими действиями. Но, в то же время, обязательно прислушивайтесь к своей интуиции.
об авторе
Котаро Ногучи работает в команде, которая создает DataSpider Servista, промежуточное программное обеспечение для предприятий, которое позволяет ИТ-командам интегрировать широкий спектр источников данных без необходимости кодирования.
