Перевод первой части статьи «Proven Code Review Best Practices».
Как проводят ревью кода в таких компаниях как Microsoft, чтобы обеспечить наилучшую обратную связь? Как сохранять продуктивность, занимаясь ревью? В этой статье мы рассмотрим лучшие подходы к проверке кода, на практике доказавшие свою эффективность.
Польза, приносимая ревью кода, может как повышаться, так и снижаться в зависимости от качества обратной связи. Если все делается правильно, ревью кода помогают обеспечить высокое качество кодовой базы. Но если в команде не знакомы с лучшими подходами к ревью и/или не следуют им, разработчики могут постоянно попадать в несколько распространенных ловушек. В самом худшем случае процесс ревью кода замедляет работу вашей команды.
Я несколько лет работал с командами в Microsoft. Проведя несколько исследований, мы нашли, какие именно подходы и практики помогают командам сохранять продуктивность и увеличивать пользу от ревью. Однако, давайте начнем с начала. Как вообще выглядит процесс ревью кода?
Обычный процесс ревью кода
Обычно процесс ревью кода (с применением специальных инструментов) начинается с подготовки кода для ревью. Затем автор кода подбирает подходящих интервьюеров для вносимых изменений. Ревьюеры получают уведомление и дают обратную связь по этому коду. Автор кода работает над замечаниями, пока все стороны не будут удовлетворены. После этого код отправляется в общую кодовую базу.
Чтобы этот процесс проходил плавно и не превратился в кошмар, важно знать о ловушках, в которые можно угодить, а также о лучших подходах, которые позволяют обойти эти ловушки.
Основные опасности, подстерегающие вас в процессе ревью кода:
- отсутствие полезного фидбэка,
- нехватка времени на ревью кода,
- ревью проходят слишком долго и служат причиной длительных простоев.
Ниже будут представлены лучшие практики проведения ревью, максимально облегчающие работу ревьюеров. Также они помогают ревьюеру сфокусироваться на предоставлении полезной обратной связи.
Лучшие практики ревью для авторов кода
В процессе ревью кода есть две разные стороны: автор кода, который обращается за обратной связью, и ревьюеры, просматривающие изменения в коде и дающие свои отзывы. Поскольку ревью кода начинается с автора, сначала мы рассмотрим лучшие практики для авторов.
Внимательно прочтите свои изменения
Автор код должен внимательно прочесть изменения, которые он вносит в код, перед отправкой кода на ревью. Нет ничего хуже, чем попросить нескольких разработчиков проверить код и высказать свое мнение по проблемам, которые вы могли бы исправить и самостоятельно.
Таким образом вы зря отнимаете у людей время и плохо выглядите в их глазах. В дальнейшем эти разработчики могут не захотеть проверять ваш код.
Поэтому обязательно используйте инструменты для ревью или diff-инструменты, подсвечивающие код – это облегчит вам процесс самостоятельной проверки вашего кода перед отправкой.
Вам часто будут попадаться забытые вами изменения или пропущенные проблемные места. Все это нужно исправить, прежде чем просить кого-то о ревью.
Вообще, лучшее время исправить все недочеты – до того, как отправите кому-то свой код.
Ваша цель – маленькие поэтапные изменения
Разработчик всегда должен стараться вносить изменения понемногу, поэтапно и последовательно. Это очень помогает при работе с инструментами контроля кода, такими как git или SVN.
Маленький размер изменений имеет большое значение и по другой причине: у разработчиков должна быть возможность быстро понять, что вы меняете в своем коде.
Если в одном ревью кода просматриваются несколько изменений, имеющих разное назначение, задача ревьюера усложняется. Это снижает его способность заметить проблемы. Проведя несколько исследований, мы увидели, что чем больше размер изменений, тем ниже качество обратной связи.
Также нужно следить за тем, чтобы изменения вносились последовательно. Изменения редко бывают слишком маленькими для отсылки на ревью. Такое случается, но не так уж часто.
Объединяйте только связанные друг с другом изменения
Представьте, что вы планируете добавить новый функционал, исправить баг в другом функционале и провести рефакторинг класса. Каждое из этих изменений следует проверять отдельно, это три разных ревью. Таким образом суть вносимых изменений будет сразу понятна ревьюерам. Это очень облегчает их работу и повышает ценность обратной связи.
Опишите цель и причину изменений
В ходе подготовки вашего кода к ревью обязательно укажите в описании, что вы меняете и почему. Это маленькое примечание поможет ревьюерам понять суть изменений, а также то, зачем вообще вы их делаете. Этот подход ускоряет процесс ревью, повышает качество и пользу фидбэка, а также улучшает показатели участия в ревью кода.
Наши исследования показывают, что разработчики-ревьюеры очень благодарны авторам кода за добавление описания изменений. В ходе опросов они высказывали пожелание, чтобы большее число людей писали подобные примечания. С другой стороны, мы заметили, что те же разработчики сами не всегда добавляют описания изменений в собственном коде.
Причина этого проста. Когда вы пишете код, вы вовлечены в контекст и в результате вам кажется, что ваш код понятен сам по себе. Но на самом деле это не так.
И если вы не поможете ревьюерам разобраться в этом коде, они не смогут дать вам хороший фидбэк.
Поэтому пишите примечания, даже если это будет простое «Обновлен API endpoint для приведения в соответствие с правилами безопасности».
Помните, что ревью кода это не головоломка!
Запускайте тесты перед отправкой кода на ревью
Да, это займет какое-то время. Но тестирование это не только одна из лучших инженерных практик, это также одна из лучших практик ревью кода. Благодаря тестированию вы удостоверитесь, что ваш код вообще рабочий, прежде чем отправите его на проверку.
Кроме того, это покажет, что вы с уважением относитесь ко времени ревьюеров. Когда на ревью посылают код, который явно не ведет себя, как положено (и это подтверждают тесты), это не только раздражает, но и плохо сказывается на продуктивности людей, вовлеченных в процесс. Так что сначала обязательно запустите тесты!
Автоматизируйте все, что можно автоматизировать
Поскольку одна из главных ловушек в ревью кода это слишком затянутый процесс, лучше автоматизировать все, что только возможно.
Используйте программы для проверки стиля, синтаксиса и прочие автоматизированные инструменты вроде статических анализаторов – это поможет вам улучшить ваш код. А ревьюерам это позволит сосредоточиться на фидбэеке и не отвлекаться на комментирование проблем, которые можно распознать автоматически.
Пропускайте ненужные ревью
Да, вы правильно прочли. Некоторые ревью можно пропустить. Конечно, это зависит от правил в вашей организации, но если они подобное допускают, подумайте о такой возможности.
Только не нужно заявлять команде, что вы больше не нуждаетесь в ревью. Пропустить проверку кода допустимо только если речь идет о каких-то тривиальных изменениях, не затрагивающих логику программы. Например, изменения в комментариях, исправление проблем форматирования, переименование локальных переменных или исправление стилистических ошибок.
Не выбирайте слишком много ревьюеров
Вам нужно отобрать подходящее число ревьюеров для проверки ваших изменений. Если вы подумали о 4, советую на этом и остановиться. Слишком большое число разработчиков, проверяющих ваш код, принесет больше вреда, чем пользы.
Если проверяющих слишком много, каждый чувствует меньшую ответственность за фидбэк (У нас есть отличная пословица на этот счет: «У семи нянек дитя без глаза». Прим. ред.). Есть и другая проблема: когда излишне много людей без необходимости заняты ревью кода, это снижает продуктивность команды.
В некоторых исследованиях советуют добавлять только двоих активных ревьюеров.
Для проверки отдельных изменений можно дополнительно привлечь экспертов, например, по безопасности, или разработчиков из других команд. Но чаще всего двоих ревьюеров вполне достаточно.
Многие инструменты для ревью кода позволяют отсылать уведомления разработчикам без назначениях их ревьюерами. Таким образом они могут быть в курсе происходящего, но без обязанности комментировать ваш код.
Чтобы получить хороший фидбэк, привлекайте опытных ревьюеров
Исследования показывают, что лучшая обратная связь исходит от ревьюеров, ранее работавших с кодом, который вы хотите изменить. Из их фидбэка вы можете многое узнать.
То, насколько часто разработчику приходилось делать ревью, тоже влияет на качество фидбэка. Более опытные разработчики и разработчики-сеньоры чаще предоставляют лучшую обратную связь.
Но не забывайте о том, что эти люди довольно загружены, поскольку их часто хотят привлечь в качестве ревьюеров.
Добавляйте в ревьюеры джуниоров, чтобы дать им возможность учиться
Одна из целей ревью кода это учеба, поэтому не забывайте подключать к делу джуниоров. Рассмотрите возможность выбора ревьюеров из людей, не знакомых с кодовой базой: это пойдет им на пользу и будет способствовать распространению знаний.
Отсылайте уведомления людям, которые как-то заинтересованы в вашем коде
Есть люди, которым стоит знать о ревью кода (при этом сами они не проводят ревью). Это могут быть, например, менеджер проекта или тимлид. Но поступайте обдуманно. Не каждый такой человек действительно беспокоится (или должен беспокоиться) по поводу проверки вашего кода.
Не уведомляйте слишком много людей
Не следует рассылать уведомления всем подряд. Ставьте в известность только людей, которым информация о процессе ревью вашего кода будет как-то полезна.
Я видел коллективы, где о ревью уведомляли всех членов команды (больше 70 человек). Это все равно, что не уведомить никого. А в худшем случае несколько ваших инженеров будут зря тратить время, просматривая уведомления о сотнях ревью, чтобы понять, какие их касаются.
Предупреждайте выбранных ревьюеров заранее
Предупредить коллег, что вскоре они получат код на проверку, это действительно очень полезная практика. Благодаря ей вам придется ждать фидбэка меньшее количество времени.
Будьте открыты для предлагаемых изменений
Получение неожиданных комментариев может вас напрягать или даже обижать. Старайтесь подготовиться к этому морально. Работайте над своей способностью воспринимать предложения и другие точки зрения. Всегда исходите из предположения, что ревьюер действует с наилучшими намерениями.
Если какой-то фидбэк вызывает у вас дискомфорт, постарайтесь прояснить ситуацию как можно быстрее. Иногда для разрешения недоразумений бывает лучше поговорить с ревьюером лично.
Выражайте свое уважение и признательность ревьюерам
Ценность ревью кода очень варьируется в зависимости от культуры обратной связи в команде. Если вы автор кода, демонстрируйте, что вы благодарны за полученный фидбэк, что для вас он ценен. Обдумывайте замечания ревьюеров и обсуждайте их.
Сообщайте ревьюерам о предпринятых вами действиях и решениях, принятых на основе их замечаний.
В следующей части статьи мы поговорим о том, как ревьюеры могут улучшить процесс проверки кода.
