Обзоры кода: многоуровневый рабочий процесс

дом

2019-07-25

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

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

1. Предварительные проверки

Не продолжайте до тех пор, пока они не пройдут:

• Сбой сборки
• Конфликты слияния

Обращают на себя внимание автора, если чрезмерное время (~ 30 минут) истекло без подтверждения.

2. Понимание

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

• Намерение / назначения
• Шаги для достижения конечной цели
• Ожидаемый результат
  • Для ошибок: то, что также ожидается не произойдет

Это должно быть ясно из описания ОР, комментариев и / или отношения к заявке. Если нет, попросите разъяснений у автора.

3. Юзабилити-тест

Подтвердите, достигает ли PR своей цели визуально и функционально.

• Пока не стоит смотреть код, если он не работает
  • Это также задерживает умственное напряжение рецензента, пока оно действительно не требуется

Обычно зарезервированы для PR, которые вносят достаточные изменения и / или риск. Если сомневаетесь, сделайте это.

Шаги:

1. Проверить ветку на местном
2. Держите консоль открытой, чтобы проверять наличие ошибок
   • Установите флажок «Приостановить исключения» в инструментах разработчика (Firefox, Chrome), чтобы не пропустить их
3. Убедитесь, что требования к истории / ошибке выполнены
4. Попробуй сломать. Если это сломается:
   1. Сначала сделайте скриншоты / записи
      • На всякий случай, если ошибка исчезнет позже
      • Также легче показать, чем рассказать в комментариях PR.
   2. Выясните шаги для воспроизведения
      • Ошибка подтверждения или отклонения также возникает в новой среде, если это возможно
        • Заманчиво продолжать тестирование на одном и том же env навсегда
5. Если возможно, сравните с юзабилити-тестом в более старой среде (например, QA, prod).
   • Обеспечивает понимание того, что должно / не должно происходить
   • Полезно для быстрого A / B-тестирования

4. Обзор кода

Посмотрите на фактический код / ​​разницу в PR.

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

Советы:

• Видите лес, а не деревья; расставить приоритеты над синтаксисом в критике
• Будьте конструктивны
• Выбирайте «мы», а не «вы» или «я»
  • Минимизировать эго, максимизировать ценность (для продукта, команды и т. Д.)
• Тупые вопросы становятся гораздо менее глупыми, если вы немного исследуете и сначала исчерпываете свои собственные ресурсы
  • Вы часто отвечаете на свой вопрос, одновременно изучая что-то самостоятельно

---

Рассуждая

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

Начало в этом слое может привести к более ранней усталости и к дополнительной работе .

Ранняя усталость

Это как тренировка. Вы не начинаете с самого тяжелого веса или самой высокой скорости беговой дорожки, что приводит к быстрому истощению и / или травме.

Проверки кода могут быть тренировкой, они истощают время и умственную энергию.

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

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

Подробнее Работа

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

Если код проверяется, но другие уровни этого не делают, рецензент должен работать в обратном направлении. Это приводит к:

• Больше ожидания.
• повторение большей части рабочего процесса проверки для того же PR.
• больше психического напряжения.

Если только шаг проверки кода завершен, тогда вероятность ошибок выше, и существует риск, что QA отправит билет обратно, что запустит весь процесс для всех.

Если нет проблем:

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

Если проблемы решаются позже, начиная с нижней части потока и работая в обратном направлении, то они оказывают большее влияние:

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

Заключение

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

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