Зачем нужно Code Review и как его проводить

В этой статье тезисно озвучу свои мысли по поводу того зачем нужно делать code review и как его делать с пользой. Возможно все эти мысли просты и очевидны, но хочется закрепить их в печатном виде. К тому же часто встречаю отзывы от разработчиков, которые недовольны тем, как у них в команде происходит ревью кода, либо оно вообще отсутствует.

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

Зачем нужен Code Review

Зачем нужно делать ревью кода? Есть несколько причин для этого:

  • Повышение качества кода. В процессе code review находится часть ошибок, которые можно исправить не отправляя ветку в тестирование. А часто бывает так, что найденные ошибки и вовсе не могут быть обнаружены тестировщиками, спокойно уходят в прод и только там обнаруживаются, неся за собой значительные потери.
  • Bus factor. Этот фактор говорит о том, какое количество разработчиков должен «сбить автобус», чтобы ваш проект встал. Под фразой «быть сбитым автобусом» понимается любое выбывание разработчика из команды — увольнение, болезнь, рождение ребенка и пр. С помощью code review большее число разработчиков погружается в код, видят вживую участки, написанные коллегами, тем самым снижая влияние фактора на разработку продукта.
  • Распространение знаний о кодовой базе в узком смысле. В процессе ревью кода может выясниться, что программист изобрел очередной велосипед, может быть написанный код дублирует уже существующий, в том числе по функционалу. В таком случае code review позволит распространять знания между разработчиками о коде.
  • Обмен знаниями в широком смысле. Code review помогает распространять в команде знания об архитектуре проекта, особенностях языка, оптимизации задача. Это важный момент для новичков в команде и для начинающих программистов.
  • Одинаковый стиль проекта. Если у команды есть разработанный и внедренный code style, проведение code review позволит разработчикам выработать у себя привычку к этому стилю. Конечно, на помощь приходят различные утилиты и ide, которые могут форматировать код по заданным параметрам. А чтение чужого кода, написанное с соблюдением стиля позволит быстрее выработать чувство этого самого стиля. И наоборот, при отступлении от принятых правил в оформлении кода, автор может быть оперативно наставлен на правильный путь. Кроме официального code style также прорабатывается и распространяется в команде и неофициальный подход к решению схожих задач. Как итог, вырабатывается общее с коллегами понимание кода, подход к написанию и чужой код читается и правится в случае необходимости практически как свой собственный.

Подходы к Code Review

Для начала необходимо обсудить особенности code review внутри команды. Например, можно выяснить и четко определить, что значат approve, reject, комментарий к коду. Это важно, потому что разные разработчики могут придавать разные значения этим действиям. Для одних reject пулл реквеста может выглядеть чем-то страшным, говорящим о том, что разработчик не справился с задачей и следует полностью переписывать код. Для других — reject всего лишь какая-то ошибка, которую нужно поправить в коде и тогда он получит аппрув. О таких моментах и нужно договориться еще «на берегу», чтобы в дальнейшем не было недопонимания и обид. Особенно важно обсудить это с junior-программистами.

Следует объяснять и в дальнейшем поддерживать позицию того, что code review — это не страшно, ревьер не стремится оскорбить или унизить разработчика, а всегда и в любом случае высказывает свое мнение о коде, о том как можно повысить его качество. Code review помогает развиваться и быстрее влиться в команду, перед ним не должно быть страха, не должно быть негатива. Разработчикам может быть сложно принимать критику в адрес своего кода с одной стороны и легко уйти в критику чужого кода. Нужно следить, чтобы в команде не было таких крайностей.

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

В результате code review могут возникать споры, в которых каждая сторона должна руководствоваться аргументами. Если у ревьюера нет весомых аргументов, почему он предлагает сделать реализацию иной, следует оставить код без изменений. Если все же не получается прийти к обоюдному согласию, необходимо выбрать третьего участника, которые и разрешит конфликт в одну или другую сторону.

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

При проведении code review следует стараться избегать неинформативных ссылок на другие комментарии. Что-то вроде «смотри комментарий выше», «аналогичному предыдущему комментарию» значительно затрудняют последующий разбор и исправление замечаний. Комментарий к блоку кода должен быть понятен сам по себе, по возможности не допуская разночтения.

Процесс проведения code review будет полезно обсуждать лично с каждым новичком команды, еще лучше, если все договоренности в виде тезисов будут зафиксированы в документе.

Важно, что ревьюить код должны все разработчики в команде, не зависимо от статуса — junior, middle, senior, совсем начинающий — каждый может быть полезен в этом деле и каждому оно может быть полезно. Команде следует понимать, что нет ничего противоестественного, страшного или неприятного в том, что junior критикует код senior-разработчика или наоборот.

Ревью кода должно иметь приоритет выше собственных задач. Иначе будет сильно тормозиться процесс разработки. Если тянуть с code review, получится что и сам автор кода может что-то подзабыть и уже сфокусироваться на другой задаче, к тому же так сделанная задача, но имеющая замечания к коду, может задержаться в релизе.

Что нужно помнить при создании pull request

При создании pull request, перед тем как код уйдет на code review следует помнить о следующих пунктах:

  • менять архитектуру решения уже поздно. Это значит, что архитектура решения должна прорабатываться в лучшем случае на этапе постановки задачи. Либо в процессе ее выполнения. Но никак не после создания пулл реквеста. Если в процессе code review возникает понимание, что сделанная архитектура не подходит к решению задачи, либо решение не работает, следует искать причину проблемы в постановке и обсуждении задачи в процессе написания кода.
  • pull request должен быть небольшим. Желательно, чтобы и сами задачи были небольшими. Много кода сложно смотреть, долго и может быть неинтересно. Отсюда пониженное внимание ревьюера и меньшее количество комментариев.
  • в описании пулл реквеста следует детально описать проблему и то, как она была решена. Это облегчит понимание ситуации ревьюером и повысит количество полезных комментариев.
  • перед созданием внимательно следует посмотреть на свой код, на создаваемый пулл реквест. Вероятно на глаза попадутся некоторые ошибки, которые были незамечены при разработке. Например, ошибочно добавленный в гит файл. Или не добавленный.

Что нужно делать при просмотре pull request

У ревьюера, в свою очередь, тоже должен быть план осмотра кода:

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

Как сделать качественное code review

Итак, вот и добрались до самого важно — code review. Как сделать его эффективным, полезным и безвредным для всех?

  • Не нужно писать комментариев ради комментариев. Пишите только по существу.
  • По возможности нужно советовать и предлагать решения, там где это уместно.
  • При этом всегда нужно следить за тоном сообщений. Сам по себе текст не передает эмоциональную окраску комментария, но различные слова могут настроить разработчика, чей код критикуется, негативно. Нужно стараться избегать таких оборотов и писать замечания вежливо или максимально нейтрально.
  • В комментариях необходимо избегать токсичности. Не нужно игнорировать комментарии к коду, игнорировать вопросы к коду. Недопустим сарказм или осуждающие вопросы. Со своей стороны также не стоит игнорировать токсичное поведение других участников ревью. Нужно на него реагировать и разбирать такие моменты, чтобы не допускать в будущем. Не стоит забывать о сотрудничестве. В любом случае ревьюер и разработчик — одна команда.
  • Не нужно бояться задавать вопросы к автору кода. Там где ревьюеру что-то непонятно или показалось новым или необычным решение задачи. Так и ревьюер сможет открыть для себя что-то новое.
  • Также стоит хвалить автора кода за удачные и изысканные решения. Да и вообще за красивый качественный код.

Следуя описанным принципам, можно максимизировать пользу от code review как для всей команды, так и для каждого ее участника по отдельности.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">