После проведения сотни code rewiew, лично возглавив R&D (Research & Development) команду и спровоцировав несколько непреднамеренных ошибок, я решил поделиться своими выводами о том, как правильно выстроить процесс проведения code rewiew.
Давайте сформулируем несколько простых причин, почему вы вообще должны прибегать к code rewiew:
- Может помочь уменьшить количество ошибок в коде.
- Поможет убедиться, что все требования по оформлению кода соблюдены.
- Это эффективный способ обучиться чему-нибудь новому у своих коллег и ознакомиться с данной базой кода.
- Помогает придерживаться единого стандарта по оформлению кода всей вашей команде.
- Сплачивает команду — code rewiew стимулирует разработчиков общаться друг с другом и вместе придумывать решения проблем.
- Улучшает общее качество кода.
Тем не менее code rewiew может стать одним из самых сложных и трудоемких этапов в процессе разработки программного обеспечения.
Мы все с этим сталкивались. Сначала вы ждете несколько дней, пока ваш код будет рассмотрен. После рассмотрения кода вы начинаете раз за разом отсылать эксперту свой код, но уже с поправками. Вы тратите недели, разрываясь между новыми функциями и старыми коммитами, которые все еще требуют полировки.
Если процесс проведения code rewiew был неправильно спланирован, затраты на его проведение будут превышать конечную ценность.
Вот почему крайне важно правильно организовать и выстроить четко определенный процесс проведения code rewiew в вашей команде.
Как правило, необходимо иметь четко определенные инструкции до создания pull-запроса и во время проверки кода, как для эксперта (рецензента), так и для того, чей код будут проверять.
Необходимые предварительные условия для создания pull-запросов.
Я пришел к выводу, что следующие условия чрезвычайно помогают в снижении количества разногласий:
- Убедитесь, что код успешно компилируется.
- Прочитайте и прокомментируйте свой код.
- Создайте и запустите тест, который проверит на ошибки область видимости вашего кода.
- Весь код в кодовой базе должен быть протестирован.
- Соедините релевантные задачи/вопросы в своей системе для отслеживания ошибок и управления проектом (например, в Jira) cо своим pull-запросом.
- Не “приглашайте” эксперта, пока не завершите все вышеизложенные пункты.
Обязанности того, чей код проверяют
- Общайтесь со своим рецензентом. Предоставьте своему рецензенту полную информацию о задаче. Поскольку многие из авторов pull-запросов уже когда-то были рецензентами, просто поставьте себя на место рецензента и задайте вопрос: “Как я могу облегчить себе задачу?”
- Делайте небольшие pull-запросы. Небольшие pull-запросы — это лучший способ ускорить время проведения code rewiew. С помощью небольших pull-запросов вы можете быстрее и точнее выполнять итерации. Как правило, небольшие изменения кода также легче тестировать и верифицировать, как стабильные. Когда pull-запрос невелик, рецензентам легче понять контекст и логику.
- Избегайте изменений во время code review. Важные изменения в середине code rewiew сводят на нет весь процесс code review. Если вам необходимо внести серьезные изменения после отправки review, вы можете отправить существующий review и дополнить его нужными изменениями. Если вам необходимо внести серьезные изменения после начала процесса code review, сообщите об этом рецензенту как можно раньше.
- Отвечайте на все замечания, которые будут сделаны вам во время code review.Даже если вы не собираетесь придерживаться этих замечаний, ответьте на них и объясните свою позицию. Если вы чего-то не понимаете, не стесняйтесь задавать вопросы во время или после code review.
- Code reviews — это совместные обсуждения, а не беспрекословное следование чьим-то указам. Большинствозамечаний во время code review можно рассматривать как рекомендации, а не приказы. Абсолютно нормально не соглашаться с замечаниями рецензентов, но необходимо объяснить почему и дать им возможность ответить на вашу позицию.
Обязанности рецензента.
- Внимательно ознакомьтесь с описанием задачи и требованиями.
- Убедитесь, что вы полностью понимаете код.
- Анализируйте все компромиссы в архитектуре.
- Разделите ваши замечания на 3 категории: Критические, Необязательные и Положительные. Первые категории — это те замечания, которые разработчик должен согласиться исправить, а последняя — это те замечания, которые позволяют разработчику понять, какие куски кода у него получились лучше всего.
Кроме того, избегайте чересчур большого количества замечаний и используйте Github review (см.пример ниже)
Если у вас есть несколько замечаний, вы должны использовать опцию review в Github, вместо того, чтобы по отдельности добавлять замечания и уведомлять об этом разработчика, когда закончите.
И наконец, я обнаружил, что, если вы будете задавать следующие вопросы — это поможет вам упростить и улучшить процесс code review:
- У меня возникают трудности в понимании этого кода?
- Есть ли в коде какое-либо сложное место, сложность которого можно уменьшить путем рефакторинга?
- Являются ли имена классов интуитивно понятными и очевидно ли то, что они делают?
- Есть ли какие-либо слишком большие классы?
- Есть ли какие-либо слишком длинные методы?
- Являются ли имена методов интуитивно понятными?
- Код хорошо документирован?
- Код хорошо протестирован?
- Есть ли способы сделать этот код более эффективным?
- Соответствует ли код стандартам оформления вашей команды?
Перевод статьи Assaf Elovic: Code Review — The Ultimate Guide
