Проверка кода проводилась задолго до появления модели запроса на извлечение. Вот четыре метода, которые стоит знать, чтобы помочь вашей команде проверить код.

Многие инженеры, читавшие мой блог, знают, что я много говорю о проверке кода. Я твердо верю, что здоровая практика проверки кода является важным инструментом для создания отличной команды. Легче создавать отличное программное обеспечение, если люди чувствуют себя достаточно безопасно, чтобы задавать вопросы, щедро делятся своими знаниями и приветствуют отзывы. Обзоры кода помогают создавать все эти вещи.

Но многие инженеры считают, что единственный способ проверить код — использовать модель запроса на извлечение. Запросы на вытягивание — это метод проверки кода по умолчанию — мои заметки о проверке кода также сосредоточены на модели запросов на вытягивание, включая мою готовящуюся книгу! — но это не единственный способ просмотреть код.

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

Просмотр размеров

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

Скорость

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

Тщательность

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

Сотрудничество

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

Сохранение знаний

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

Пулл-реквесты

Запросы на включение являются стандартом в отрасли. Первоначально воплощенный в жизнь GitHub, этот процесс позволяет разработчику вносить набор изменений в код (обычно в ветку) и запрашивать, которые сопровождающий (или соавтор) извлекает или объединить их код с основной веткой.

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

Многие инструменты также хорошо работают с моделью запросов на вытягивание. Линтеры, автоматизированные тесты и т. д. могут запускаться и сообщать о состоянии каждого действия в запросе на вытягивание — все со ссылками и визуальными очередями. Проверки процесса (не забыл ли автор обновить журнал изменений или применить правильные теги) здесь также полезны.

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

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

Запросы на вытягивание, как правило, выполняются быстро (хотя это горячие споры), если размер запроса не слишком велик. Чем больше запрос (обычно измеряется изменением общего количества строк), тем больше времени требуется на рассмотрение.

Запросы на вытягивание также прилично оцениваются по совместной работе. Во многом этому сотрудничеству способствуют инструменты, разработанные GitHub (или другими поставщиками git SaaS), чтобы легко предлагать изменения в строке или комментировать изменения в целом. Однако многие инженеры не любят процесс запроса на вытягивание, ссылаясь на то, что асинхронный характер запроса на вытягивание приводит к дополнительной задержке в системе (что правильно). Однако, по моему опыту, это время ожидания заметно только тогда, когда команда еще не работает вместе.

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

Официальные обзоры

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

Распространенный подход к формальным проверкам называется проверка Фагана — процесс, названный в честь инженера-программиста Майкла Э. Фагана. Фэган был исследователем в IBM и был пионером в области проверки программного обеспечения. Его техника является методичной и предписывающей для каждого этапа обзора и того, как его следует проводить, включая этапы до и после каждой встречи, на которой фактически происходит обзор. Не все формальные обзоры носят такой предписывающий характер, как у Фэгана, но они часто требуют больше накладных расходов, чем просто просмотр кода.

Эти накладные расходы приводят к тому, что формальные проверки занимают больше времени и требуют гораздо меньше совместной работы, чем другие форматы проверок. Мы все испытали, насколько сложно запланировать встречу с четырьмя или пятью участниками, что приводит к увеличению времени ожидания. Кроме того, после получения обратной связи инженер может быть отправлен для работы в одиночку для внесения необходимых изменений. Затем у них есть еще одна встреча, чтобы запланировать второй раунд обзора. Это похоже на бесполезную бюрократию в современном мире программного обеспечения Agile…

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

Формальные проверки теперь часто предназначены для наиболее важных и безопасных кодовых баз. Беспилотные автомобили, медицинские устройства и т. д. — все это кандидаты на такую ​​проверку.

«через плечо»

Over should — это именно то, на что это похоже: инженер приглашает коллегу заглянуть через его плечо, чтобы перепроверить их работу или посмотреть вместе с ними на конкретную проблему.

Хотя этот метод может по ощущениям не совпадать с проверкой кода, он определенно им является. Один инженер просит другого инженера просмотреть его код, чтобы получить помощь, направление или даже быстрое подтверждение.

Обзоры через плечо выполняются быстро и часто требуют очень мало усилий. Это делает их идеальными для небольших, сплоченных команд, работающих вместе над одним продуктом или проектом.

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

Интересно, что, поскольку оперативные обзоры часто фокусируются на конкретной потребности или проблеме, они не поощряют тесного сотрудничества. Однако они могут привести к созданию сеанса парного программирования, который (как мы увидим далее) требует тесного сотрудничества.

Где страдают обзоры через плечо, так это в области сохранения знаний. Если пара инженеров обнаружила новый фрагмент знаний во время совместной работы, у них нет естественного места для хранения этих знаний (по крайней мере, нет места, расположенного непосредственно рядом с кодом). Даже если бы это было так, может быть сложно сделать эти знания доступными для других членов команды, поскольку контекст — изменение, над которым они работали, — может быть легко утерян.

Парное программирование

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

Эти роли часто называют Водителем и Навигатором. Водитель отвечает за написание кода, а Навигатор ищет мелкие ошибки и стратегически думает о направлении, в котором будет двигаться код. Часто пара инженеров по очереди меняет каждую роль.

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

Проверка слишком запоздала. Качество, хорошее или плохое, уже заложено в продукте.

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

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

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

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

Пейринг также не решает проблему сохранения знаний. Два инженера (или, возможно, больше, если используется групповое программирование) могли принять решение о коде для рефакторинга чего-либо, но никогда не сообщать остальной команде, почему было принято это решение. Если другой член команды пытается понять изменение, ему, вероятно, придется попросить одного из этих инженеров объяснить, почему.

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

Фу! Это было много! Спасибо, что остаетесь там.

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

Но все они ценны сами по себе.

Удачного кодирования! (и пересматриваю!)

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

Первоначально опубликовано на https://dangoslen.me.