Дерек Прайор - разработчик в Thoughtbot, где у них сильная культура проверки кода. В этом интервью Дерек рассказывает о преимуществах проверки кода и основных элементах, которые, по его мнению, необходимы для их эффективности.
Читайте больше интервью с некоторыми из лучших разработчиков мира в нашем блоге или подписывайтесь на нас в Twitter.
Больше, чем просто отловить ошибки
"Намного полезнее сосредоточиться на культурных преимуществах проверки кода"
Что касается преимуществ проверки кода, «естественная реакция всех - говорить, что они отлавливают ошибки. Это правда. Если у меня есть проверенный код, в нем будет меньше ошибок, чем в коде, который не проверялся. Но я думаю, что это придает слишком большое значение «поиску ошибок», - говорит Приор. «Гораздо полезнее сосредоточиться на культурных преимуществах проверки кода», которых, по его мнению, много. От «обмена знаниями друг с другом или того, что все делают», до «знания того, что происходит в этой другой части кодовой базы, и поиска действительно интересного альтернативного решения проблемы, о которой они не задумывались».
Для Prior преимущества Code Review выходят далеко за рамки простого поиска дефектов - «найти дефекты на самом деле, честно говоря, очень сложно. Я много раз говорю с людьми о проверках кода, и они говорят: «Ну, мы проводили проверки кода, но у нас все еще были все эти ошибки». Но они не поймают всех ошибок. Вы смотрите на разницу, и чтобы точно знать, как это действительно повлияет на вашу систему, вам нужно знать всю систему ». Итак, хотя «проверка кода отлично подходит для поиска дефектов, это не панацея». Вместо этого, я думаю, гораздо полезнее сосредоточиться на культурных преимуществах проверки кода », - говорит Прайор.
Сделайте их частью своего рабочего процесса
«Я много раз нахожу, что могу просто работать с ними естественным образом. Их не нужно планировать »
Один из способов убедиться, что после того, как вы начнете с обзоров кода, вы будете их придерживаться, является «действительно легкий подход к этому», - рекомендует Прайор. Например, «когда я закончу PR, я вставлю его в Slack или что-то еще. Мы вставим это и скажем: «Могу я получить обзор для этого, пожалуйста?», И в целом этого достаточно, с учетом того, как мы работаем, чтобы проверить ваш код в течение следующих нескольких часов », - говорит Приор.
Быстрая обработка кода важна, и не нужно быть обременительным, чтобы оставаться на вершине. Прайор предполагает, что на самом деле существует «много естественных перерывов в течение дня, в которых вы можете поработать». «Что касается меня, я прихожу утром» и узнаю обо всех проверках кода за ночь. «Тогда прямо перед обедом или во второй половине дня, если я собираюсь сделать перерыв на кофе… тогда я посмотрю». «Я много раз нахожу, что могу просто работать с ними естественным образом. Нет необходимости их планировать. Я работал с командами, которые пытались их составить по расписанию или пытались сказать: «Этот человек будет тем, кто в основном будет проводить обзоры кода на этой неделе», и я никогда не видел, чтобы это работало особенно хорошо ». .
Вместо этого вам просто нужно «сделать его легким и дружелюбным», - говорит Прайор. «Самая важная вещь, которая делает эту работу, - это сохранение небольших дискретных запросов на вытягивание, которые будет намного легче проверять, если вы предоставите отличный контекст. Это «почему» вы вносите это изменение, а не обязательно «что». Но «в конечном итоге главный секрет этого, - признается Прайор, - в том, что большая часть этих проверок кода занимает у меня всего пять минут. Это не большое обязательство ".
Что включать в обзор кода
«Просто посмотрите на то, что вас интересует в переменах»
«Отчасти я считаю, что обзор кода так хорош, так это то, что это отличное место для технической дискуссии о вашем реальном программном обеспечении. Скорее, чем абстрактно », - говорит Приор. Он не поддерживает идею использования контрольного списка или конкретных пунктов, предлагая более расслабленный подход - «просто посмотрите на то, что вас интересует в изменении». «Может быть, вы только что дочитали эту замечательную книгу о шаблонах проектирования. Это ценно. Вы собираетесь кого-то чему-то научить. Или, может быть, вы действительно заинтересованы в веб-безопасности ... или доступности ». Что касается меня, - говорит Прайор, - я много говорю о именах… Я ищу тестовое покрытие ». Как бы то ни было, до тех пор, пока у вас есть «хорошая смесь в вашей команде, люди, которые интересуются разными вещами», вы «можете учиться друг у друга».
Контекст - это ключ
"Это действительно помогает, если вы делали несколько небольших коммитов по пути"
«Главное - это контекст, - говорит Прайор. «Когда вы отправляете пул-реквест, вы работали над этим четыре часа, восемь часов, два дня, а иногда и неделю, или в любом другом случае. У вас в голове много контекста. Некоторые вещи сейчас кажутся вам действительно очевидными ». Однако следует помнить, что «для человека, просматривающего его, их там не было… у них нет этого контекста». «Это действительно помогает, если вы делали несколько небольших коммитов по пути, где вы описываете то, что было у вас в голове», но, тем не менее, «по мере того, как вы готовите изменение ... убедитесь, что вы все хорошо описываете».
Это описание должно ответить на вопрос: «Почему мы его меняем?», - говорит Приор. Другие соображения: «Почему это лучшее решение? Какие еще решения вы рассматривали? С какими проблемами столкнулись? Есть ли часть кода, в которой вы действительно не уверены? " Все это «поможет вам получить гораздо лучший обзор, настроив всех остальных на одну страницу с вами», - говорит Прайор.
Сохраняйте положительные отзывы
«Конфликты в ваших проверках кода на самом деле очень полезны»
Приор предупреждает, что «когда проверка кода выполняется не очень хорошо или слишком критично, она может вызвать недовольство в команде». Одна вещь, о которой вы должны знать, - это то, что письменное общение склонно к предвзятости, - говорит Прайор. «Если я говорю с вами и дам вам техническую обратную связь, и я говорю:« О, почему вы не использовали здесь этот шаблон », вы будете воспринимать это одним способом. Но если я скажу то же самое, что записано, это будет казаться более резким. Вы будете воспринимать это более негативно. Это гораздо больше зависит от вашего настроения. Я не могу повлиять на это тем, как я что-то говорю. Это просто факт, что тот же отзыв будет восприниматься более негативно ». Так что это тоже следует учитывать при обзоре кода.
Прайор рекомендует отличный способ обойти это - «давать обратную связь в форме, которая больше похожа на разговор». Что мне нравится делать, так это задавать вопросы… Вместо того, чтобы говорить: «Извлеките объект службы здесь, чтобы уменьшить часть этого дублирования», я бы сказал: «Эй, что вы думаете об извлечении объекта службы здесь, чтобы исключить это дублирование? «Это очень похожие комментарии, но теперь я открываю их для разговора, задав вам вопрос». Еще одно предложение Прайора - «прояснить, насколько сильно вы относитесь к обратной связи».
Тем не менее, время от времени конфликт все равно будет происходить. Но для Прайора «такой конфликт в ваших проверках кода на самом деле действительно полезен ... пока они являются конфликтами правильного типа, и никто впоследствии не чувствует себя плохо из-за них. Если вы все время соглашаетесь со своими товарищами по команде, и в ваших проверках кода не происходит ничего интересного, по сути, у вас монокультура. Вы хотите, чтобы каждый привносил свой собственный опыт и свои знания, а иногда они будут противоречить друг другу ». Но если вы сможете «правильно справиться с этими конфликтами», - говорит Прайор, - то «этому все в команде будут учиться».
Читайте больше интервью с некоторыми из лучших разработчиков мира в нашем блоге или подписывайтесь на нас в Twitter.
