Зачем мы проводим обзоры кода?

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

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

Мои советы

Тщательно формулируйте комментарии

Помните, что человек, код которого вы проверяете, вероятно, приложил много усилий, и он не намеренно допустил ошибки, особенно те, которые легко пропустить, орфографические ошибки и т.д.

Старайтесь не быть слишком душераздирающим, когда оставляете комментарии.

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

Измените имя этой переменной

скажите что-то вроде:

Возможно, это можно было бы назвать более описательным именем переменной.

Таким образом, предложение по улучшению будет сделано, но так, чтобы кодер чувствовал, что у него все еще есть право голоса / вопрос открыт для обсуждения.

Будьте ясны и лаконичны.

Говорите прямо и четко о том, что вы хотите изменить или что советуете. Не виляйте вокруг да около, просто скажите “Что” и “Почему”.

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

Хостинг-провайдеры, такие как GitHub, имеют функцию “suggestion”, которая позволяет добавить предложение кода прямо в комментарий, который может быть мгновенно принят и зафиксирован из PR.

Несколько одинаковых изменений.

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

Не все кодируют так же, как вы

Помните, что не все кодируют одинаково и, конечно, не всегда кодируют так, как вы. Это не значит, что они ошибаются, и не значит, что ваш способ лучше.

Всегда делайте шаг назад и думайте о ключевых элементах проверки кода.

• Соответствует ли код руководящим принципам кодирования вашей команды

• Соответствует ли код поставленной цели / критериям приемки.

• Является ли код разборчивым и легко ли понять, что он делает, без необходимости в пространных комментариях / документации. (Для меня этот пункт является одним из самых важных, так как я большой поклонник описательных имен методов и переменных.

• Нуждается ли код в рефакторинге, учитывая безопасность, производительность или просто удобство чтения.

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

Вот некоторые из моих советов, надеюсь, они были полезны.

Не стесняйтесь обсуждать свои советы и методы обзора кода в комментариях.