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

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

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

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

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 (см. пример ниже).

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

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

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

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

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

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