13,8 тыс подписчиков

Code Review - Полное руководство

4 минуты

103 прочтения

15 февраля 202015 фев 2020

Оглавление

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

После проведения сотни 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:

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