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

Время выполнения изменений — это время, которое требуется для перехода в рабочую среду, и оно является частью четырех ключевых показателей, определяемых исследованием и оценкой DevOps (DORA). Команды инженеров стремятся оптимизировать эту задержку, чтобы как можно быстрее предоставить выгоду своим клиентам. Но прежде чем предлагать решения, давайте сначала определим проблему:

Что во время проверки кода может замедлить весь процесс, создать узкие места и увеличить время выполнения изменений?

Технический директор Promyze Артур Магне недавно обсуждал эту тему с Фредди Маллетом и Марсело Соуза из Reviewpad во время вебинара, и мы резюмировали здесь основные мысли.

Сужение контекста и цели проверки кода

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

Сначала спросите себя:

Действительно ли необходим каждый код-ревью? Можем ли мы утверждать, что все обсуждения в обзорах актуальны и должны там происходить?

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

Утверждение кода №1

Мне нужно убедиться, что мой код в порядке перед слиянием ⇒ Мне нужно ваше одобрение

В этом случае могут возникнуть разногласия с обеих сторон, так как проверка происходит поздно. Авторы могут воспринимать отзывы как ограничение, которое замедляет их доставку, и разочарование, когда они получают много комментариев, с которыми они не всегда соглашаются. Рецензенты также могут вести себя защитно. Что, если они подумают: «Я бы не сделал [код] таким образом. Должен ли я рассказать об этом? Должен ли он блокировать слияние? Мой коллега ждет 2 дня; как мой отзыв будет принят?» Таким образом, вы можете видеть, что трения могут возникать из-за проверки кода, главным образом потому, что мы испытываем давление, вызванное поиском удовлетворительного времени выполнения для изменить.

# 2 Получите помощь, чтобы улучшить код

Я хотел бы показать вам свой код и получить ваши отзывы, чтобы улучшить его ⇒ Мне нужна ваша помощь.

По сравнению с пунктом № 1, мы стремимся улучшить наш код и учиться у коллег. В этом контексте стоит подумать, является ли этот обзор частью процесса доставки. Мы можем быть уверены, что этот код может быть объединен первым. Это то, что обычно наблюдается в транковой разработке.

Рабочие процессы и политики различаются в зависимости от контекста PR, поэтому имеет смысл дать ему четкое определение.

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

Нужны ли нам проверки кода?

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

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

«Программное тестирование может быть использовано для того, чтобы показать наличие ошибок, но не для того, чтобы показать их отсутствие!»

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

Теперь давайте вернемся к нашему основному вопросу: как решить вышеупомянутые проблемы?

Делайте обзоры кода только тогда, когда это имеет смысл

Концепция Fluid Pull Request

Чтобы ответить на вопрос: Все ли запросы на слияние требуют проверки кода?, мы можем изучить модель Ship Show Ask. При таком подходе считается, что авторы PR не имеют права оценивать себя, если:

  • Код не требует проверки кода, так как изменения тривиальны (отправить)
  • Они хотели бы показать изменения кода коллегам и получить их отзывы (Показать); Этот режим может звучать совершенно неестественно, так как обратная связь может быть предоставлена ​​​​после слияния. Это часть смены парадигмы.
  • Код требует проверки (спросить)

Таким образом, вместо того, чтобы добавлять больше человеческих ресурсов для проверки кода, мы пересматриваем необходимость утверждения каждого PR; Вот как мы можем положительно повлиять на время выполнения изменений. Эта концепция также называется Fluid Pull Request.

Запросы на вытягивание следующего поколения с помощью Reviewpad

Reviewpad — это приложение GitHub, предназначенное для автоматизации процесса проверки кода и реализующее концепцию Fluid Pull Request. Один файл конфигурации в вашем репозитории Git будет содержать все ваши рабочие процессы и политики для ваших запросов на вытягивание. В зависимости от контекста вы определите правила, чтобы усилить или ослабить вашу сеть безопасности. С помощью Reviewpad вы можете определить такие правила, как:

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

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

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

api-version: reviewpad.com/v3.x
labels:
  critical:
    description: Modifications to critical changes
    color: "#294b75"
groups:
  - name: owners
    description: Group of owners
    kind: developers
    spec: '["marcelosousa", "ferreiratiago"]'    
workflows:
  - name: changes-to-critical-code
    always-run: true
    if:
      - rule: '$hasAnnotation("critical")'
      - rule: '$hasFileName("runner.go")'
    then:
      - '$addLabel("critical")'
      - '$assignReviewer($group("owners"), 1)'
      - '$info("@marcelosousa: you are being notified because critical code was modified")'

Обсуждайте передовой опыт и проектируйте вне код-ревью

Обмен знаниями должен быть коллективным

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

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

Обмен передовым опытом с Promyze

Promyze — это платформа для обмена знаниями между разработчиками, обеспечивающая интеграцию с IDE и проверку кода (GitHub, GitLab, Azure DevOps, Bitbucket и Helix Swarm). С помощью плагинов проверки кода вы можете создать наилучшую практику написания кода из комментария, и код будет отправлен в Promyze вместе с вашим предложением по лучшей практике. Таким образом, вы избегаете долгих дискуссий один на один во время проверки кода.

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

Хотите ускорить проверку кода?

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

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

Мы также показали, что Reviewpad и Promyze могут дополнять друг друга, ускоряя проверку кода и способствуя обмену знаниями.

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