Google: How to handle reviewer comments
Google, основываясь на многолетнем опыте, представил свои стандарты того, как лучше всего проводить code review. Все вместе они представляют собой один законченный документ, разбитый на множество отдельных разделов. Это перевод стандартов по проведению Code Review от Google. Вот ссылка на оригинал!
Терминология:
CL — расшифровывается как «список изменений» (“ChangeList”), что означает одно автономное изменение, которое было отправлено в систему управления версиями или подвергается проверке кода. Другие организации часто называют это «изменением» или «патчем».
Как обрабатывать комментарии ревьюеров
Когда вы отправили CL на проверку, вполне вероятно, что ваш ревьюер добавит несколько комментариев к вашему CL. Вот, что нужно знать при обработке комментариев ревьюера.
Не принимайте все на свой счет
Целью проверки кода является поддержание качества вашего репозитория и ваших продуктов. Когда ревьюер делает критические замечания по вашему коду, думайте об этом, как о попытке помочь вам, а не как о личной нападке на вас или ваши способности.
Иногда ревьюеры чувствуют разочарование и выражают его в своих комментариях. Это не очень хорошая практика для ревьюеров, но как разработчик вы должны быть к этому готовы. Спросите себя: «Что ревьюер пытается донести до меня?», а затем воспользуйтесь его советами.
Никогда не отвечайте в гневе на комментарии к коду. Это серьезное нарушение профессиональной этики, которое навсегда останется в инструменте проверки кода. Если вы слишком раздражены, чтобы отвечать доброжелательно, сделайте паузу на некоторое время или поработайте над чем-нибудь еще, пока не успокоитесь, чтобы ответить вежливо.
В общем, если ревьюер не дает обратную связь конструктивным и вежливым образом, пообщайтесь с ним лично. Если вы не можете поговорить с ним с глазу на глаз или по видео-связи, отправьте ревьюеру личное письмо. Объясните ему, что именно вам не нравится. Если конструктивной реакции не последует, то обратитесь к своему менеджеру.
Исправление кода
Если ревьюер говорит, что он не понимает что-то в вашем коде, вы должны сначала уточнить сам код. Если код не может быть разъяснен, добавьте комментарий, объясняющий этот код. Если комментарий к коду неуместен, сделайте пояснение в инструменте проверки кода.
Если ревьюер не понимает отдельный фрагмент вашего кода, вероятно, другие разработчики тоже его не поймут. Написание ответа в инструменте проверки кода не поможет будущим разработчикам, но ваш комментарий в коде будет весьма кстати.
Думайте сами
Создание каждого CL занимает много времени и сил. И зачастую приятно, наконец, отправить его на рассмотрение с уверенностью, что дальнейшая работа не потребуется. Поэтому, когда ревьюер добавляет комментарии к коду, то можно подумать, что комментарии излишние, и ревьюер блокирует вас без веской причины. Но даже если вы уверены в этом, попробуйте сделать шаг назад и подумайте о том, что, возможно, ревьюер дает ценный фидбек, который действительно улучшит ваш код. Ваш первый вопрос к себе всегда должен быть: «Прав ли ревьюер?». Если вы не можете ответить на этот вопрос, вероятно, ревьюер должен уточнить свои комментарии.
Если вы все-таки не согласны с комментариями, не стесняйтесь объяснить, почему ваш подход лучше для репозитория и пользователей. Зачастую ревьюеры всего лишь дают советы и хотят, чтобы вы сами решили, как лучше сделать. Возможно, вы на самом деле знаете что-то о пользователях, репозитории или CL, чего не знает ревьюер. Поэтому дайте им больше информации о CL и его контексте. Скорее всего, вы придете к согласию, основываясь на технических фактах.
Разрешение конфликтов
Делая первый шаг в разрешении конфликта, попытайтесь прийти к согласию с вашим ревьюером. Если вы не можете достичь консенсуса, смотрите “Стандарты проверки кода”, в которой приведены принципы, которым необходимо следовать в такой ситуации.
