Обзоры кода — важная часть предоставления качественного кода. Это не только помогает поддерживать качество проекта, но и формирует привычку писать хороший код. Мы должны помнить одну вещь: тщательная и подробная проверка кода требует времени.
В команде, где так много кода запущено в производство несколькими разработчиками
- Менеджеры по продуктам и инженеры должны уделять достаточно времени проверке кода.
- У нас могут быть рекомендации, мы должны попытаться использовать правила Eslint или правила Tslint, поскольку автоматизация лучше, чем ручные инструкции. Но не все вещи можно автоматизировать, поэтому мы можем установить правила. У нас могут быть рекомендации по соглашению об именах в html, css или javascript. Таким образом, эти рекомендации очень помогают поддерживать согласованность кода.
Мы можем следовать этим вещам, чтобы улучшить процесс проверки кода.
- Каждый запрос на включение должен иметь правильное описание изменений.
- Если изменение касается каких-либо изменений пользовательского интерфейса, мы можем добавить скриншоты, все возможные случаи пользовательского интерфейса — это очень помогает рецензенту.
- Если возможно, добавьте правильное видео всей функции, охватывающее все потоки и случаи UX.
- Каждая функция может иметь комментарии в стиле документа JS, и это хорошо.
- Мы можем убедиться, что одна функция выполняет одну функцию, а затем извлекает ее в отдельную функцию.
- Каждый запрос на включение не должен превышать 300–500 строк. Поскольку рецензент может лучше просматривать код и легче выявлять ошибки, чем просматривает большой запрос на вытягивание. Если ошибки могут быть обнаружены в процессе проверки кода, это поможет вам отправить в производство наименьшее количество ошибок или код без ошибок.
- Всегда добавляйте
/TODO or /TODO : refactor or /TODO write unit test
`, это помогает в дальнейшем собирать вещи - Проверка кода не дублируется
- Если параметр принимает более 4 параметров, лучше использовать объект и передавать в нем аргументы.
- Проверка возможности кэширования чего-либо
- Убедитесь, что весь код покрыт тестами
У нас могут быть следующие автоматические проверки кода
- Убедитесь, что покрытие кода не будет падать ни на один из запросов на вытягивание, если оно будет заблокировано (зависит от того, пишет ли ваша команда тесты).
- Покрытие Flow JS или машинописный текст также не терпят неудачу
- Ustory для тестирования компонентов пользовательского интерфейса можно использовать, если что-то изменилось в компоненте.
Тестирование
- Все независимые функции могут быть охвачены тестированием с помощью jest.
- Для компонента мы можем написать тест, используя
Обработка непредвиденных случаев
Мы знаем, что иногда мы на 102% уверены, что значения всегда придут, но хорошо справляться с крайними случаями.
Тон проверки кода
Просмотры кода важны, но важен и тон проверки. Если мы проводим код-ревью с агрессивным языком