Обзор кода — широко распространенная практика для большинства текущих проектов. Во всех командах, с которыми я работал, это было обязательным. Но это не значит, что всегда было хорошо. Или даже немного полезно.

Почему это? Из-за отношения разработчиков к этому процессу. В некоторых случаях это было не только пустой тратой времени, но и усугубляло ситуацию.

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

Давайте катиться!

1) Рассмотрение только с технической стороны

Проверка кода касается не только качества кода. Это важная часть, и вы не должны пренебрегать ею. Но проверка кода — это гораздо больше. Речь идет о том, чтобы убедиться, что код, который вы проверяете, выполнит свою работу. Если вы просматриваете часть новой реализации, обязательно ознакомьтесь с бизнес-требованиями этой функции и проверьте, соответствует ли написанный код этим требованиям.

Это утомительно — вы можете подумать. Но никто не говорил, что код-ревью — это легкий процесс. Это сложно. И ответственность.

Самый простой способ проверить, правильно ли человек понял бизнес-требования, — проверить модульные тесты. Во-первых, они есть? Включают ли они крайние случаи?

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

2) Не брать на себя ответственность

Проверка кода обычно является частью вашей работы. И вы несете ответственность за то, чтобы сделать эту работу хорошо, а это значит, что поверхностного взгляда на код недостаточно. Даже после того, как вы нажмете кнопку Одобрить, вы станете таким же ответственным за этот код, как и тот, кто его написал, и если возникнет какая-то серьезная проблема — вы будете в равной степени виноваты.

Так что вы либо тратите достаточно времени на этот процесс, либо вообще отказываетесь от него.

Не делайте работу наполовину.

3) Использование «мне это не нравится» в качестве аргумента

Есть так много способов сделать одно и то же — даже больше, чем один. И да, может так случиться, что другой человек предпочтет другой метод. Здесь нет никакой трагедии. И не надо начинать священную войну из-за используемого паттерна или даже его отсутствия. Легко ли понять код? Соответствует ли требованиям? Тогда все в порядке. Вы бы сделали это по-другому? Это не имеет значения.

4) Без учета временных ограничений

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

5) Невежливость

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

Мое эмпирическое правило — оставлять комментарии в форме вопроса.

— Может быть, лучше сделать это по-другому? звучит намного лучше, чем «Сделай это по-другому!».

В конце концов, вы хотите поддерживать хорошие отношения со своей командой.

Кратко

Делая код-ревью, проверяйте как техническую реализацию, так и соответствие кода требованиям. Будьте внимательны, так как вы несете ответственность за свой отзыв. Не тратьте время на споры о лучших практиках — мнений больше, чем одно. Учитывайте текущий статус проекта и предлагайте масштабные изменения только в том случае, если есть время для их внесения. И, конечно же, всегда будьте вежливы.