Главное Свежее Вакансии   Проекты
Продвинуть свой проект
45 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Код-ревью — краткое руководство

“Хороший код и комментарии интересные!”Все мы слышали о пользе ревью кода, но так ли это на самом деле?Если процесс ревью кода не спланирован правильно, это принесет больше вреда, чем пользы.Как получать только пользу, ищите в новой статье.

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

b_5c665edc14c93.jpg

Статья предполагает, что вы уже знаете, что такое код-ревью, если нет, прочитайте это.

Причины, по которым следует делать ревью кода:

  1. Код-ревью уменьшает количество ошибок в коде.
  2. Можно убедиться, что все требования выполнены.
  3. Поддерживается один стиль кода для всей команды.
  4. Повышает сплоченность команды — поощряйте обсуждение лучших практик и стандартов написания кода.
  5. Улучшается качество кода.

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

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

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

Вот почему крайне важно структурировать и четко строить процесс проверки кода в команде.

Необходимы четко определенные рекомендации как для рецензента, так и для рецензируемого, до создания pull request и во время его рассмотрения.

Определите обязанности рецензируемого

Хоть рецензент последний в цепочке слияния PR, чем лучше сделан PR рецензируемым, тем меньше рисков в долгосрочной перспективе.

Вот некоторые рекомендации, которые помогут:

  1. Общайтесь с рецензентом — предоставьте рецензентам дополнительную информацию о вашей задаче. Поскольку большинство из нас, вероятно, уже были рецензентами, поставьте себя на место рецензента и спросите: «Насколько легко это было бы для меня?»
  2. Делайте небольшие pull requests — маленькие PR - лучший способ ускорить время проверки. Оставляйте PR небольшими, чтобы итерации выполнялись быстрее и точнее. Как правило, небольшие изменения кода легче тестировать и проверять на стабильность. Так рецензентам легче понять контекст и логику.
  3. Избегайте изменений во время ревью кода — значительные изменения в середине проверки кода в основном сбрасывают весь процесс проверки. Если вам необходимо внести изменения после отправки PR, вы можете отправить существующий код и внести дополнительные изменения. Если вам необходимо внести серьезные изменения после запуска процесса проверки кода, обязательно сообщите об этом рецензенту как можно раньше.
  4. Реагируйте на все замечания после проверки кода — Даже если вы не будете вносить изменения предложенные рецензентом, ответьте на них и приведите аргументы. Если что-то непонятно, задавайте вопросы внутри или вне ревью кода.
  5. Ревью кода - это обсуждение, а не распоряжение— Большинство замечаний о проверке кода можно рассматривать как предложения, а не как приказ. Это нормально, не соглашаться с замечаниями рецензента, но объясните почему и дайте возможность ответить.

Определите обязанности рецензента

На рецензенте лежит большая ответственность.

Рецензент должен:

  1. Хорошо знать описание тасков и требования.
  2. Убедиться, что полностью понимает код.
  3. Оценить все компромиссы архитектуры.
  4. Разделять свои комментарии на 3 категории: критические, дополнительные и положительные. Первые - это комментарии, которые разработчик должен принять, чтобы внести изменения, а последние - это благодарность за хороший код.

Избегайте множества комментариев и используйте Github review (см. пример ниже).

b_5c6660cfda5f5.jpg

Когда у вас есть несколько комментариев, используйте опцию review в Github и уведомите разработчика (владельца PR), когда закончите.

Спустя годы работы, я понял, что вопросы ниже - отличный инструмент для улучшения и упрощения ревью кода:

  • У меня есть трудности в понимании этого кода?
  • Есть ли какая-либо сложность в коде, которая может быть уменьшена путем рефакторинга?
  • Хорошо ли организована структура кода?
  • Названия (имена) классов интуитивно понятны и очевидно ли, что они делают?
  • Есть ли классы, которые особенно большие?
  • Есть ли какие-то особенно длинные методы?
  • Все ли названия методов понятны?
  • Код хорошо документирован?
  • Код хорошо протестирован?
  • Есть ли способы сделать этот код более эффективным?
  • Соответствует ли код стандартам нашей команды?

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

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

Перевод Code Review — The Ultimate Guide от Digital Skynet

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Первые Новые Популярные
Комментариев еще не оставлено
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.