День девятьсот восемьдесят первый. #Оффтоп #CodeReview
Обзоры Кода. Передовой Опыт. Окончание
Начало
Продолжение

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

1. Ошибки требований
Разработчик мог неправильно понять некоторые требования. Его код может быть протестирован на 100%, но, если и код, и написанные тесты основаны на неправильных предположениях, задача не может считаться выполненной.

2. Изменения пользовательского интерфейса
Создание правильного UI, который сделает пользователей продуктивными, - одна из самых сложных задач разработки. Проверка кода и проверка UI специалистами команды являются обязательными, чтобы убедиться, что продукт развивается в правильном направлении.

3. Трудно находимые ошибки
Ошибки, связанные с параллельной обработкой (взаимоблокировки, состояния гонки и т.п.), трудно обнаружить, трудно воспроизвести и трудно исправить. Младшие разработчики часто их допускают, даже не подозревая, что они могут произойти. При обзоре кода опытный программист сможет оценить, возможно ли возникновение ошибки. Например, он проверит изменение общего состояния и чистоту метода. Также могут быть обнаружены некоторые другие сложные ошибки, включая утечку памяти и проблемы производительности, вроде проблемы N+1 запроса.

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

5. Именование
Для обеспечения соблюдения простых требований к именованию могут быть написаны автоматические правила. Также инструментальные средства могут заставить использовать предопределённую терминологию основного домена. Кроме того, правильное именование особенно важно для публичных идентификаторов API. Вот почему требуется тщательный анализ именования человеком.

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

7. Последовательность
Часто молодые участники команды заново изобретают колесо, потому что не знакомы с общекорпоративными шаблонами и библиотеками. Некоторые автоматические правила могут быть написаны для принудительного использования определённых классов в определённых ситуациях. Но обзоры кода представляют собой отличный способ рассказать о культуре и базе знаний компании.

8. Комментарий
Комментарии должны быть написаны тщательно на правильном человеческом языке, чтобы объяснить, почему этот код написан и почему написан именно таким образом. Например, когда какой-то нетривиальный код адаптируется из ответа со Stackoverflow, стоит указать URL ответа и контекст. С другой стороны, код должен быть достаточно читабельным, чтобы не нужно было комментариев, объясняющих, что он делает.

9. Документация
Инструменты могут легко обнаружить недостающую документацию. IDE, вроде Visual Studio, может легко сгенерировать скелет класса или документацию метода. Но документация пишется человеком и для человека. Чтобы она была действительно информативной, необходима надлежащая проверка со стороны человека. Мы, разработчики, регулярно разочаровываемся в поверхностной и устаревшей документации, которая на самом деле не объясняет, зачем нужен API, как его следует использовать и чего от него ожидать. Правильная документация - отличный способ снизить затраты на поддержку и снизить разочарование пользователей.

Источник: https://blog.ndepend.com/what-is-code-review-guidelines-best-practices/