В нашей статье об эффективных ревью кода мы рекомендовали использовать чеклист. Чеклисты (контрольные списки) — это великая вещь в ревью: они гарантируют, что ревью действительно прошло через вашу команду. Также они способствуют выявлению и решению общих трудностей.
Исследование, проведенное Software Engineering Institute, показывает, что программисты делают 15-20 распространенных ошибок. Добавив такие ошибки в чеклист, вы можете быть уверены, что заметите их в момент появления и поможете от них избавиться надолго.
Чтобы вам было от чего отталкиваться, вот вам список типичных пунктов:
Вы также можете захотеть добавить в этот чеклист любые вещи, специфичные для вашего языка и способные вызвать проблемы.
Чеклист сознательно не охватывает всех возможных проблем. Вам не нужен контрольный список, который настолько длинный, что никто его не использует. Лучше всего покрыть им только общие вопросы.
Не бойтесь выбрасывать из чеклиста те элементы, которые вам не подходят (вы можете захотеть оставить редко встречающиеся, но все же критические пункты — например, связанные с безопасностью).
Еще одна хорошая идея — поделиться списком с вашей командой и получить их согласие с его содержимым. Периодически просматривайте и сам чеклист для проверки, что каждый пункт в нем все еще актуален.
Вооружившись хорошим чеклистом, вы можете увеличить количество дефектов, обнаруживаемых во время ревью кода. Это позволит вам улучшить стандарт кодирования и избежать плохого качества ревью.
Чтобы узнать больше о ревью кода, вы можете ознакомиться с видео на нашей странице.
Исследование, проведенное Software Engineering Institute, показывает, что программисты делают 15-20 распространенных ошибок. Добавив такие ошибки в чеклист, вы можете быть уверены, что заметите их в момент появления и поможете от них избавиться надолго.
Чтобы вам было от чего отталкиваться, вот вам список типичных пунктов:
Чек-лист CodeReview
Общее
- Работает ли код? Выполняет ли он свои прямые обязанности, корректна ли логика, и т. д.
- Легок ли код для понимания?
- Соответствует ли код вашему стилю написания кода? Обычно это относится к расположению скобок, названиям переменных и функций, длинам строк, отступам, форматированию и комментариям.
- Есть ли в ревью избыточный или повторяющийся код?
- Является ли код независимым, насколько это возможно?
- Можно ли избавиться от глобальных переменных или переместить их?
- Есть ли закомментированный код?
- У циклов есть установленная длина и корректные условия завершения?
- Может ли что-то в коде быть заменено библиотечными функциями?
- Может ли быть удалена часть кода, предназначенного для логгирования или отладки?
Безопасность
- Все ли входные данные проверяются (на корректный тип, длину, формат, диапазон) и кодируются?
- Обрабатываются ли ошибки при использовании сторонних утилит?
- Выходные данные проверяются и кодируются (прим. пер.: например, от XSS)?
- Обрабатываются ли неверные значения параметров?
Документация
- Есть ли комментарии? Раскрывают ли они смысл кода?
- Все ли функции прокомментированы?
- Есть ли какое-то необычное поведение или описание пограничных случаев?
- Использование и функционирование сторонних библиотек документировано?
- Все ли структуры данных и единицы измерения описаны?
- Есть ли незавершенный код? Если есть, должен ли он быть удален или помечен маркером типа «TODO»?
Тестирование
- Является ли код тестируемым? Например, он не должен содержать слишком много зависимостей или скрывать их, тестовые фреймворки должны иметь возможность использовать методы кода, и т. д.
- Есть ли тесты и если есть, то достаточны ли они? Например, они покрывают код в нужной мере.
- Юнит-тесты на самом деле проверяют, что код предоставляет требуемую функциональность?
- Все ли массивы проверяются на «выход за границы»?
- Может ли любой тестирующий код быть заменен с использованием существующего API?
Вы также можете захотеть добавить в этот чеклист любые вещи, специфичные для вашего языка и способные вызвать проблемы.
Чеклист сознательно не охватывает всех возможных проблем. Вам не нужен контрольный список, который настолько длинный, что никто его не использует. Лучше всего покрыть им только общие вопросы.
Оптимизируйте свой чеклист.
Этот чеклист можно использовать в качестве отправной точки: вам нужно оптимизировать его под ваши специфичные сценарии и проблемы. Отличный способ сделать это — отмечать вопросы, которые возникают в вашей команде во время ревью кода в течение короткого времени. С этой информацией вы сможете найти самые распространенные ошибки команды, чтобы затем внести их в ваш чеклист.Не бойтесь выбрасывать из чеклиста те элементы, которые вам не подходят (вы можете захотеть оставить редко встречающиеся, но все же критические пункты — например, связанные с безопасностью).
Начните использовать и держите в актуальном состоянии
Как правило, любые пункты чеклиста должны быть конкретными и, если возможно, давать вам однозначный ответ на ваш вопрос. Это помогает избежать непоследовательности суждений.Еще одна хорошая идея — поделиться списком с вашей командой и получить их согласие с его содержимым. Периодически просматривайте и сам чеклист для проверки, что каждый пункт в нем все еще актуален.
Вооружившись хорошим чеклистом, вы можете увеличить количество дефектов, обнаруживаемых во время ревью кода. Это позволит вам улучшить стандарт кодирования и избежать плохого качества ревью.
Чтобы узнать больше о ревью кода, вы можете ознакомиться с видео на нашей странице.