Об ошибках в первом код-ревью рассказывает Александр Моргунов, наставник на программе «Мидл фронтенд-разработчик» в Яндекс.Практикуме, ментор в командной работе.
Чем код-ревью отличается от тестирования
И код-ревью, и тестирование нужны, чтобы найти и исправить ошибки в коде. При этом задача ревьюера — разобраться в логике решения, а не просто проверить код на ошибки, как на этапе тестирования.
Во время код-ревью разработчик может заметить громоздкое решение и предложить вариант, как сделать код проще и понятнее. Например, использовать уже написанную для другого фрагмента функцию вместо того, чтобы создавать новую.
Дальше расскажу об ошибках в код-ревью, которые я часто замечал у начинающих разработчиков.
1. Не проводят код-ревью совсем
Проекты, в которых не проводится код-ревью, впоследствии будет сложнее поддерживать. А молодые специалисты будут дольше вливаться в проект и медленнее развиваться технически, ведь опытные коллеги не будут давать им обратную связь и подсказывать, как сделать код лучше.
Я встречал пару проектов, на которых было не принято проводить код-ревью. Задачи там выполнялись долго, а разработчики особо не заботились о качестве кода, так как никто его не смотрел.
2. Не уточняют цель и задачи проекта перед проверкой
Задача ревьюера — проверить не столько сам код, а то, насколько эффективно он решает поставленную задачу. Если ревьюер не понимает, зачем этот код написан и что решает, он вправе уточнить это у автора кода. В идеале автор должен тезисно описать это в связанном тикете или в комментарии к код-ревью, тогда этот вопрос автоматически снимается.
Не поверите, но чаще всего трудности возникают из-за непонятной задачи, а не из-за изменений в коде.
3. Акцентируют внимание на стиле и синтаксисе
Не тратьте время на замечания по пропущенным точкам с запятой и лишним пробелам. Эту часть проверки можно делегировать автоматическим утилитам. Например, для фронтенд-разработки я рекомендую использовать связку ESLint, Prettier, Husky и Stylelint.
ESLint помогает описать стиль JavaScript или TypeScript-кода. Prettier позволяет в автоматическом режиме дополнительно форматировать код (не только JavaScript). Husky форматирует код перед коммитом, а Stylelint поддерживает CSS в порядке.
Эти инструменты позволяют писать код в одном стиле всем разработчикам. Читать такой код намного проще: не обращаешь внимание на стилистику и не задумываешься об оформлении кода во время ревью. Код-ревьюер вместо того, чтобы писать кучу замечаний по стилю, сконцентрирован на логике работы программы.
Пример, когда проверяющий делает замечание, которое относится к синтаксису
Совет ревьюера относится лишь к оформлению кода, но не несёт никакой смысловой нагрузки.
Также, чтобы не тратить ресурсы ревьюера на проверку стайлгайда, я советую сделать единое руководство по стилю кода. Для описания руководства достаточно создать Markdown-файл в репозитории и задокументировать в нём все правила.
4. Не проверяют тесты
Я часто замечал, что новички бегло просматривают тесты и спешат проверить раздел реализации. Тесты — это тоже код, который требует проверки. Не забывайте про него.
5. Пишут токсичные комментарии
Главное правило: ревьюер оценивает не автора, а код. Поэтому сообщение «ты плохо написал функцию» стоит как минимум заменить на «эта функция не решает поставленную задачу» или «эта функция дублирует другую функцию». Правило «критикуешь — предлагай» здесь тоже работает, поэтому не забывайте добавлять к комментариям предложения, как можно было бы сделать код лучше.
Агрессивные комментарии заставляют автора занять оборонительную позицию. В такой ситуации сложно давать конструктивную обратную связь и вместе находить удачные решения.
В сообщении ревьюера нет агрессии, но оно может задеть автора, если в отношениях между автором и ревьюером не всё гладко
6. Запрашивают недописанный код на ревью
Код-ревью стоит запрашивать, когда код полностью написан. Если возникают сомнения в правильности написании кода или выбранном архитектурном решении, обсудите это со старшими коллегами. Чем быстрее вы это сделаете, тем больше времени сэкономите себе и им.
Ещё один совет для новичков: не пытайтесь подготовить к код-ревью идеальный код, чтобы старшие коллеги «не поругали». Скорее всего, это отнимет у вас слишком много времени. Пишите код в обычном режиме, а на ревью вам обязательно подскажут, если что-то стоит улучшить.
Сервис онлайн-образования Яндекс.Практикум помогает освоить новую профессию в ИТ: учёба проходит в тренажёре, а в конце обучения студентам помогают с поиском работы. Летом команда запустила мидл-курсы для тех, кто уже разбирается в программировании и хочет прокачать свои навыки. На курсе мы погружаем студентов в устройство современных фреймворков и учим решать сложные задачи самостоятельно.