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

  • Менеджеры по продуктам и инженеры должны уделять достаточно времени проверке кода.
  • У нас могут быть рекомендации, мы должны попытаться использовать правила Eslint или правила Tslint, поскольку автоматизация лучше, чем ручные инструкции. Но не все вещи можно автоматизировать, поэтому мы можем установить правила. У нас могут быть рекомендации по соглашению об именах в html, css или javascript. Таким образом, эти рекомендации очень помогают поддерживать согласованность кода.

Мы можем следовать этим вещам, чтобы улучшить процесс проверки кода.

  • Каждый запрос на включение должен иметь правильное описание изменений.
  • Если изменение касается каких-либо изменений пользовательского интерфейса, мы можем добавить скриншоты, все возможные случаи пользовательского интерфейса — это очень помогает рецензенту.
  • Если возможно, добавьте правильное видео всей функции, охватывающее все потоки и случаи UX.
  • Каждая функция может иметь комментарии в стиле документа JS, и это хорошо.
  • Мы можем убедиться, что одна функция выполняет одну функцию, а затем извлекает ее в отдельную функцию.
  • Каждый запрос на включение не должен превышать 300–500 строк. Поскольку рецензент может лучше просматривать код и легче выявлять ошибки, чем просматривает большой запрос на вытягивание. Если ошибки могут быть обнаружены в процессе проверки кода, это поможет вам отправить в производство наименьшее количество ошибок или код без ошибок.
  • Всегда добавляйте /TODO or /TODO : refactor or /TODO write unit test`, это помогает в дальнейшем собирать вещи
  • Проверка кода не дублируется
  • Если параметр принимает более 4 параметров, лучше использовать объект и передавать в нем аргументы.
  • Проверка возможности кэширования чего-либо
  • Убедитесь, что весь код покрыт тестами

У нас могут быть следующие автоматические проверки кода

  • Убедитесь, что покрытие кода не будет падать ни на один из запросов на вытягивание, если оно будет заблокировано (зависит от того, пишет ли ваша команда тесты).
  • Покрытие Flow JS или машинописный текст также не терпят неудачу
  • Ustory для тестирования компонентов пользовательского интерфейса можно использовать, если что-то изменилось в компоненте.

Тестирование

  • Все независимые функции могут быть охвачены тестированием с помощью jest.
  • Для компонента мы можем написать тест, используя

Обработка непредвиденных случаев

Мы знаем, что иногда мы на 102% уверены, что значения всегда придут, но хорошо справляться с крайними случаями.

Тон проверки кода
Просмотры кода важны, но важен и тон проверки. Если мы проводим код-ревью с агрессивным языком