Код-ревью — краткое руководство
За свою карьеру я провел сотни обзоров кода, возглавлял команды, совершал непреднамеренные ошибки, поэтому могу поделиться опытом, как улучшить ревью кода.
Статья предполагает, что вы уже знаете, что такое код-ревью, если нет, прочитайте это.
Причины, по которым следует делать ревью кода:
- Код-ревью уменьшает количество ошибок в коде.
- Можно убедиться, что все требования выполнены.
- Поддерживается один стиль кода для всей команды.
- Повышает сплоченность команды — поощряйте обсуждение лучших практик и стандартов написания кода.
- Улучшается качество кода.
Однако ревью кода может быть одной из самых сложных и трудоемких частей разработки программного обеспечения.
Все мы через это проходили. Вы ждали несколько дней, пока код будет рассмотрен. После этого, начинается “пинг-понг” с рецензентом для повторной отправки pull request. На это уходят недели. Вы переключаетесь между новыми фичами и старыми коммитами, которые все еще нуждаются в изменении.
Если процесс ревью кода не спланирован правильно, это принесет больше вреда, чем пользы.
Вот почему крайне важно структурировать и четко строить процесс проверки кода в команде.
Необходимы четко определенные рекомендации как для рецензента, так и для рецензируемого, до создания pull request и во время его рассмотрения.
Определите обязанности рецензируемого
Хоть рецензент последний в цепочке слияния PR, чем лучше сделан PR рецензируемым, тем меньше рисков в долгосрочной перспективе.
Вот некоторые рекомендации, которые помогут:
- Общайтесь с рецензентом — предоставьте рецензентам дополнительную информацию о вашей задаче. Поскольку большинство из нас, вероятно, уже были рецензентами, поставьте себя на место рецензента и спросите: «Насколько легко это было бы для меня?»
- Делайте небольшие pull requests — маленькие PR - лучший способ ускорить время проверки. Оставляйте PR небольшими, чтобы итерации выполнялись быстрее и точнее. Как правило, небольшие изменения кода легче тестировать и проверять на стабильность. Так рецензентам легче понять контекст и логику.
- Избегайте изменений во время ревью кода — значительные изменения в середине проверки кода в основном сбрасывают весь процесс проверки. Если вам необходимо внести изменения после отправки PR, вы можете отправить существующий код и внести дополнительные изменения. Если вам необходимо внести серьезные изменения после запуска процесса проверки кода, обязательно сообщите об этом рецензенту как можно раньше.
- Реагируйте на все замечания после проверки кода — Даже если вы не будете вносить изменения предложенные рецензентом, ответьте на них и приведите аргументы. Если что-то непонятно, задавайте вопросы внутри или вне ревью кода.
- Ревью кода - это обсуждение, а не распоряжение— Большинство замечаний о проверке кода можно рассматривать как предложения, а не как приказ. Это нормально, не соглашаться с замечаниями рецензента, но объясните почему и дайте возможность ответить.
Определите обязанности рецензента
На рецензенте лежит большая ответственность.
Рецензент должен:
- Хорошо знать описание тасков и требования.
- Убедиться, что полностью понимает код.
- Оценить все компромиссы архитектуры.
- Разделять свои комментарии на 3 категории: критические, дополнительные и положительные. Первые - это комментарии, которые разработчик должен принять, чтобы внести изменения, а последние - это благодарность за хороший код.
Избегайте множества комментариев и используйте Github review (см. пример ниже).
Когда у вас есть несколько комментариев, используйте опцию review в Github и уведомите разработчика (владельца PR), когда закончите.
Спустя годы работы, я понял, что вопросы ниже - отличный инструмент для улучшения и упрощения ревью кода:
- У меня есть трудности в понимании этого кода?
- Есть ли какая-либо сложность в коде, которая может быть уменьшена путем рефакторинга?
- Хорошо ли организована структура кода?
- Названия (имена) классов интуитивно понятны и очевидно ли, что они делают?
- Есть ли классы, которые особенно большие?
- Есть ли какие-то особенно длинные методы?
- Все ли названия методов понятны?
- Код хорошо документирован?
- Код хорошо протестирован?
- Есть ли способы сделать этот код более эффективным?
- Соответствует ли код стандартам нашей команды?
Существуют и другие эффективные методы проверки кода, которые различаются в зависимости от потребностей команды. Возможно, не всё, что я рассказал, подойдет вам. Создание единого процесса ревью кода должно учитывать цели компании, культуры команды и общей структуры проектов.
Если вы знаете другие способы, как улучшить код-ревью, пишите в комментариях.
Перевод Code Review — The Ultimate Guide от Digital Skynet