Код-ревью для новичков: 8 советов для эффективной работы

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

1. Просматривайте не больше 400 строк кода за раз

Команда программистов Cisco в сотрудничестве со SmartBear Software провела крупнейшее в мире исследование по проверке кода. Они проанализировали 2500 код-ревью — 3,2 миллиона строк кода за 10 месяцев. Результаты показали, что мозг может эффективно обрабатывать не больше 200–400 строк кода за раз. При превышении этого количества способность обнаружить баги уменьшается. На практике проверка 200–400 строк в течение 60–90 минут позволяет обнаружить от 70 до 90% проблем в коде.

Чтобы каждый раз не считать количество изменённых строчек кода, можно на уровне проекта ввести правило об объёме кода, который отправляется на ревью. Если кода намного больше, просить автора разбить результат на несколько частей.

Но и в таких правилах бывают исключения. Например, количество изменённых строчек кода в package-lock.json, который фиксирует зависимости, измеряется тысячами. В этом случае не нужно сразу бежать к автору и просить разбить результат на части. По изменениям в любом случае стоит пробежаться, чтобы понять их масштаб.

2. Не проверяйте код больше 60 минут подряд

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

3. Не торопитесь

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

4. Фиксируйте задачи

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

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

Для небольших задач мы в команде используем специальный шаблон, состоящий из двух пунктов: «Зачем делать?» и «Что делать?» В первом пункте фиксируется продуктовая или иная мотивация, во втором тимлид или автор задачи расписывают шаги, необходимые для выполнения задачи.

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

5. Нормируйте внутренние показатели проверки

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

Примеры нормируемых показателей:

• скорость проверки;
• количество ошибок, обнаруженных за час проверки;
• плотность дефектов (среднее количество ошибок, обнаруженных на строку кода).

Показатели скорости проведения ревью и количество найденных ошибок довольно субъективны: если ревьюер начнёт делать ревью быстрее или закапываться, стараясь находить как можно больше ошибок, будет страдать качество самого ревью. Эти показатели будут индивидуальны для каждой команды, отталкивайтесь от уровня подготовки команды.

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

Более-менее объективный показатель — количество переоткрытий пулл-реквестов. Он позволяет выявить разработчиков, которые сразу пишут хороший код (ревью проходит с первой попытки), и тех, у кого ревью проходит с трудом (возможно, таким разработчикам сложно выполнять текущие задачи и им нужна помощь).

Для больших команд или в командах, где задачи зависают в статусе «Требуется код-ревью», я рекомендую дополнительно вводить SLA (Service Level Agreement, соглашение об уровне сервиса) на время реакции на пулл-реквест. Именно на время реакции, а не на проведение код-ревью, потому что разработчик может быть занят критичными задачами. В нашей команде, например, SLA — 24 часа.

Возможно, ваши менеджеры уже используют эти показатели, так что будьте внимательны.

6. Сделайте ревью обязательной частью процесса разработки

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

7. Контролируйте области, которые охватывает код-ревью

Хорошая проверка покрывает новый код и то, как он вписывается в кодовую базу: его корректность, тесты (в предыдущей части я как раз писал, что новички любят пропускать проверку тестов), изменения функциональности и их поддержку. Опытный ревьюер проверит, как эти изменения вписываются в существующую архитектуру программного обеспечения, отметит удобство обслуживания. Его задачи — обнаружить сложную логику, которую можно упростить, улучшить структуру теста, удалить дублирования.

8. Договоритесь о статусах

После завершения проверки код можно пометить как одобренный, либо заблокировать его запросами на изменение, либо не устанавливать конкретный статус, оставив в состоянии «Ещё не утверждён».

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

В нашей команде принято использовать специальные нотации перед сообщением:

• (!) — когда ревьюер ожидает правки в обязательном порядке;
• (?) — когда есть вопрос, на который нужно получить ответ.

Если специального символа нет, комментарий можно рассматривать как рекомендацию, а исправление остаётся на усмотрение автора.

Так (!) в нашей команде отмечают комментарии, которые нужно обязательно исправить.

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