Как проверять запросы на слияние в 2022 году

Кто-то в моем сообществе [Virtual Coffee] (https://virtualcoffee.io) спросил о том, как сегодня улучшить проверку запросов на вытягивание (PR), что и побудило написать этот пост. Надеюсь, вы найдете здесь что-то полезное. Я хотел бы услышать от вас, если вы делаете! А если нет, то тоже нормально. Предложения по улучшению моего процесса приветствуются!

Сначала я прочитал заголовок и описание, чтобы понять, о чем идет речь. Если есть проблемы или другие ссылки на PR, я проверяю их, если мне нужно больше контекста. Если есть изменения пользовательского интерфейса (UI), я ищу скриншоты до и после. Если нет скриншотов и присутствуют изменения пользовательского интерфейса, я прошу рецензента включить некоторые из них. Это значительно упрощает оценку изменений с высокоуровневого взгляда.

Хорошо! Давайте запустим код, чтобы проверить это! Вау, еще не совсем.

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

Как правило, PR должен быть небольшим по нескольким причинам:

• Легче просмотреть

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

Иногда нет другого выбора, кроме как иметь значительно большой PR. Я видел это в основном в работе с пользовательским интерфейсом, но это также относится к работе с серверной частью, как правило, по сценарию «все или ничего».

Если вышесказанное не выполняется, вот причины, по которым я вижу, почему PR раздуваются:

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

• Работа, которую нужно сделать, не разбита. Выполняйте работу, которая продвигает более масштабную работу вперед. Например, функция полезности, используемая во всей функции, может быть в отдельном PR. Создает ли человек новый пользовательский интерфейс? Они могут создавать компоненты независимо друг от друга и создавать разные PR, потенциально используя для их создания такой инструмент, как Storybook.

Помните, что проблема или функция не должны сопоставляться с одним PR.

Наконец-то я смотрю на какой-то код! Я ищу проблемы, которые выделяются для меня, не снимая PR и не запуская код на моем локальном компьютере. Я не говорю о проблемах стиля форматирования/кодирования, потому что в настоящее время многие проекты имеют такие инструменты, как линтеры или средства форматирования кода.

Вещи, которые я ищу:

• логические ошибки

• языковая особенность, о которой человек может не знать, которую можно использовать в PR

• использование существующих служебных функций в кодовой базе

• тесты

• документация

• проблемы с доступностью

В некоторых случаях может возникнуть стиль кодирования, например, возврат раньше, когда условие не выполняется в функции или методе. Если во время проверки появляются изменения, которые можно изменить автоматически, автоматизируйте их! Однако сделайте это в отдельном PR. 😎

После первой проверки кода я отправляю PR рецензенту, если у меня есть запросы на изменение. Подожди секунду? Вы еще даже не запустили код? Как обозреватель, у меня тоже есть своя работа, поэтому я воздержусь от проведения тест-драйва PR.

После первоначального обзора я проверяю внесенные изменения и отзывы. Я могу предоставить больше отзывов. Когда изменений не остается (на данный момент), я вытаскиваю код и запускаю его локально. В зависимости от настройки проекта у него могут быть предварительные развертывания для PR на хосте, таком как Netlify или Vercel, или в какой-либо контейнерной среде для тестирования. Несмотря ни на что, сейчас самое время проверить намерения PR.

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

Наконец, тон обзора имеет значение. Я привык использовать структуру комментариев под названием [Обычные комментарии] (https://conventionalcomments.org). Если вам интересно узнать больше, в прошлом году я выступил с [молниеносной речью об обычных комментариях] (https://www.iamdeveloper.com/pages/talks/#heading-words-matter:-conventional-comments). Netlify создал аналогичную систему под названием [Лестницы обратной связи] (https://twitter.com/lesliecdubs/status/1420188172726771714).

Если вы дошли до этого момента, ваш PR одобрен! 😎

Спасибо и до следующего раза!

Фотография Маркуса Винклера на Unsplash

Также опубликовано здесь: https://www.iamdeveloper.com/posts/how-i-review-pull-requests-44nl/