Код-ревью для новичков: 6 самых частых ошибок

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

Чем код-ревью отличается от тестирования

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

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

Дальше расскажу об ошибках в код-ревью, которые я часто замечал у начинающих разработчиков.

1. Не проводят код-ревью совсем

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

Я встречал пару проектов, на которых было не принято проводить код-ревью. Задачи там выполнялись долго, а разработчики особо не заботились о качестве кода, так как никто его не смотрел.

2. Не уточняют цель и задачи проекта перед проверкой

Задача ревьюера — проверить не столько сам код, а то, насколько эффективно он решает поставленную задачу. Если ревьюер не понимает, зачем этот код написан и что решает, он вправе уточнить это у автора кода. В идеале автор должен тезисно описать это в связанном тикете или в комментарии к код-ревью, тогда этот вопрос автоматически снимается.

Не поверите, но чаще всего трудности возникают из-за непонятной задачи, а не из-за изменений в коде.

3. Акцентируют внимание на стиле и синтаксисе

Не тратьте время на замечания по пропущенным точкам с запятой и лишним пробелам. Эту часть проверки можно делегировать автоматическим утилитам. Например, для фронтенд-разработки я рекомендую использовать связку ESLint, Prettier, Husky и Stylelint.

ESLint помогает описать стиль JavaScript или TypeScript-кода. Prettier позволяет в автоматическом режиме дополнительно форматировать код (не только JavaScript). Husky форматирует код перед коммитом, а Stylelint поддерживает CSS в порядке.

Эти инструменты позволяют писать код в одном стиле всем разработчикам. Читать такой код намного проще: не обращаешь внимание на стилистику и не задумываешься об оформлении кода во время ревью. Код-ревьюер вместо того, чтобы писать кучу замечаний по стилю, сконцентрирован на логике работы программы.

Пример, когда проверяющий делает замечание, которое относится к синтаксису

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

Также, чтобы не тратить ресурсы ревьюера на проверку стайлгайда, я советую сделать единое руководство по стилю кода. Для описания руководства достаточно создать Markdown-файл в репозитории и задокументировать в нём все правила.

4. Не проверяют тесты

Я часто замечал, что новички бегло просматривают тесты и спешат проверить раздел реализации. Тесты — это тоже код, который требует проверки. Не забывайте про него.

5. Пишут токсичные комментарии

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

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

В сообщении ревьюера нет агрессии, но оно может задеть автора, если в отношениях между автором и ревьюером не всё гладко

6. Запрашивают недописанный код на ревью

Код-ревью стоит запрашивать, когда код полностью написан. Если возникают сомнения в правильности написании кода или выбранном архитектурном решении, обсудите это со старшими коллегами. Чем быстрее вы это сделаете, тем больше времени сэкономите себе и им.

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