Полное руководство по ревью кода

0
1159
views

Перевод статьи «Code Review — The Ultimate Guide».

Руководство по ревью кода

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

Будем считать, что само понятие «ревью кода» для вас не ново. Если нет, с ним можно ознакомиться на вики.

Давайте быстро повторим, что нам вообще дает просмотр кода:

  • Уменьшение количества багов в коде.
  • Дополнительная проверка удовлетворения всех требований.
  • Эффективный способ учиться у коллег и знакомиться с кодовой базой.
  • Поддержка определенного стиля кода внутри команды.
  • Сплоченность команды: ревью кода подталкивают разработчиков к общению друг с другом на тему лучших подходов и стандартов кода.
  • Улучшение качества кода под влиянием коллег.

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

Со всеми нами такое случалось. Сидишь и ждешь целыми днями, пока твой код просмотрят. А когда просмотрят, начинаешь «играть в пинг-понг» с ревьюером, пытаясь заново отправить пул-реквест. И неделями переключаешься между новыми фичами и старыми коммитами, в которых по-прежнему нужно что-то подправить.

Если процесс ревью кода не спланирован правильно, «затраты» на его проведение могут превысить выгоды.

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

В целом, вам нужно иметь хорошие руководства как для ревьюера, так и для автора кода. В этих руководствах должно быть расписано, что нужно сделать перед отправкой пул-реквеста и как проводить ревью. Перейдем к конкретике.

Определяем необходимые условия для создания пул-реквеста

  1. Убедитесь, что ваш код успешно компилируется.
  2. Прочтите свой код, добавьте аннотации.
  3. Соберите и запустите тесты, соответствующие области вашего кода.
  4. Весь код кодовой базы должен быть протестирован.
  5. Сделайте ссылку на относящиеся к делу тикеты в вашем инструменте для менеджмента задач (например, JIRA).
  6. Не назначайте ревьюера, пока не сделаете все вышеперечисленное.

Определяем обязанности автора кода

Чем в лучшем виде вы передадите свой код ревьюеру, тем меньше рисков это повлечет в долгосрочной перспективе. Вам могут помочь следующие рекомендации:

  1. Коммуницируйте со своим ревьюером. Представьте ему бэкграунд вашей задачи. Поскольку большинству из нас уже доводилось самим выступать в роли интервьюера, просто постарайтесь встать на его место. Спросите себя, что могло бы облегчить задачу вам, если бы ревью этого кода делали вы.
  2. Делайте более мелкие пул-реквесты. Это лучший способ ускорить ревью. Маленький размер пул-реквеста сделает возможными более быстрые и аккуратные итерации. В целом, более мелкие изменения также легче тестировать и проверять на надежность. Когда ревьюер просматривает такой пул-реквест, ему легче понять контекст и логику.
  3. Старайтесь не вносить изменений в ходе ревью. Значительные изменения, внесенные в код, который как раз проходит ревью, сводят на нет все усилия ревьюера. Если вам все же необходимо внести какие-то крупные изменения, когда вы уже отправили заявку на просмотр, имеет смысл сначала отправить код в изначальном виде, а потом послать дополнительные изменения. Если внесение изменений понадобилось, когда процесс ревью уже начался, сообщите об этом ревьюеру как можно раньше.
  4. Отвечайте на каждый фидбэк. Даже если вы не собираетесь применить рекомендуемые изменения, напишите ответ и приведите свои доводы. Если в фидбэке вам что-то непонятно, задавайте вопросы.
  5. Ревью кода это дискуссия, а не предписания. Все фидбэки, полученные после просмотра вашего кода, стоит считать предложениями, а не приказами. Если вы не согласны с ревьюером, это прекрасно. Однако вы должны обосновать свою точку зрения и дать возможность оппоненту ответить на это.
Просмотр кода

Определяем обязанности ревьюера

Поскольку ревьюер является последним звеном в цепочке перед слиянием кода, уменьшение количества ошибок в этом коде по большей части лежит именно на нем. Ревьюер должен:

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

Также стоит избегать большого количества комментариев. Вместо этого можно использовать Github review (см. пример ниже).

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

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

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

Есть много эффективных подходов к проведению ревью кода. Они варьируются в зависимости от нужд конкретной команды. План действий, изложенный здесь, это лишь мое мнение; для вашей команды вполне может подойти что-нибудь другое. Создание такой тонкой процедуры должно учитывать цели вашей компании, культуру команды и структуру разработки в целом.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here