Главная

Как делать хороший Code Review

Проверки кода способствуют улучшению командной работы, помогают разработчикам развиваться и улучшают качество кода.

1,782 

24+

“code review” с англ. — обзор/просмотр/проверка кода.
Когда я начинал свой путь программиста в качестве junior разработчика, я был счастлив. Моя работа состояла в том, чтобы написать код — проверить его — переписать код. Жизнь была проста и великолепна. Мне нужно было лишь анализировать комментарии к коду, которые я получал в результате code review, и на основе их улучшать свои навыки программирования. Но в один момент моя жизнь изменилась и меня повысили до senior разработчика. Code review стали моим повседневным занятием. Спустя некоторое время я осознал, что несмотря на то, что хорошо пишу код, мне не хватает опыта для качественных code review.

Я уходил в пятки и чувствовал себя самозванцем каждый раз, когда меня просили проверить чей-то код. Несколько вопросов не давали мне покоя:
а) Стоит ли комментировать ту или иную строчку кода.
b) Я знаю способ, как лучше написать этот класс. Стоит ли говорить об этом?
c) Что он подумает, он ведь более опытный разработчик, чем я?
d) Сломаю ли я приложение, если изменю этот блок кода?

Вот, что посоветовал мой ментор:
Основная цель хороших проверок кода состоит в получении неожиданных результатов, а не в поиске багов. Не относитесь к проверкам кода как к допросу. Вместо этого старайтесь руководствоваться политикой объективного анализа с явным намерением улучшить стиль кода, найти альтернативное решение проблемы, повысить профессионализм вас и вашего коллеги.

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

Ставьте цели и определяйте метрики

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

Скотт М. Граффиус

Вообщем-то успех состоит в балансе. Слишком много метрик — пустая трата времени, а их отсутствие похоже на плавание на корабле без компаса. Перед началом code review вы должны решить, как будете измерять эффективность и назвать несколько глобальных целей проверки.
Как правило, хороший код должен быть:
· Функциональным — он должен работать как изначально задумано.
· Чистым и поддерживаемым — он должен быть читабельным.
· Оптимизированным — работа в соответствии с ожиданиями в продакшене.

Метрики должны иметь определенные цели, чтобы гарантировать, что улучшения измеряются и отслеживаются во время и после проверки. Например, «уменьшить количество обращений в службу поддержки на 15%» или «снизить уровень внедрения дефектов на 50% во время разработки». Помните, что цели должны показать количественную картину того, как ваш код улучшается. «Исправить как можно больше ошибок» не является осязаемой целью, которая к тому же не даст никакой ценности.

Управлять (с англ. manage) можно лишь тем, что можно измерить

Альберт Эйнштейн

Критикуйте идеи, а не людей

Критика, как дождь, должна быть достаточно мягкой, чтобы питать рост человека, не разрушая его корни.

Фрэнк А. Кларк

Почему проверки кода иногда выходят из-под контроля и становятся эмоционально неустойчивыми? Это происходит, когда мы перестаем обсуждать идею и начинаем обсуждать человека, который создал эту идею. Всегда легко сказать: «Рави, ты глуп, почему ты не реализовал код для параллелизма». Но требуется благодать, уравновешенность и зрелость, чтобы сказать: «Мне интересна реализация этого кода. Как он будет обрабатывать параллелизм?»

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

Нет личностному, только профессиональное!

Задавайте вопросы до полного понимания

Вопросы — это первый шаг к изменениям

Кубра Саит

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

Вы как врач, который лечит пациента. Врач задает различные вопросы — привычки, питание, уровень стресса, лекарства, которые вы принимаете, и т. д. Затем она или он предлагает курс лечения. Человеческое тело — сложный механизм, и если доктор не будет настойчив, он никогда не сможет найти и исправить проблему.

Code review должен проходить по тому же принципу. Найджел Муньос, бывший full-stack software engineer в Muse, а в настоящее время независимый инженер-программист, рекомендует проверяющему всегда думать о том, «как то или иное изменение повлияет на общую картинку». Общая картина включает стиль и формат кода, его модульность, архитектуру и так далее.

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

Не кормите из ложки

Дай человеку рыбу, и ты накормишь его на день; научи человека ловить рыбу, и ты накормишь его на всю жизнь

Когда вы делаете проверку кода, вы выступаете в роли наставника, а хорошие наставники обучают. Вы должны привести других к решению и мотивировать их решать проблемы самостоятельно. Представьте себя организатором игры «Охота за сокровищами». Вы даете подсказки участникам, указываете правильное направление и, наконец, позволяете им самим разобраться в происходящем. У данного подхода есть ряд преимуществ:
a) Обучение и обмен опытом
b) Разработчик несет полную ответственность за код.
c) Вы воспитываете следующие поколение талантливых проверяющих.

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

Не проверяйте код более 60 минут.

Способность работать в течение нескольких дней подряд без потери фокуса и способность продолжать усваивать новую информацию после многих часов обучения — это талант.

Гарри Каспаров

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

Не просматривайте слишком много кода одновременно, ибо так у вас меньше шансов найти неисправности. Старайтесь, чтобы каждый сеанс проверки не превышал 400 строк. Установка ограничения на строки важна по тем же причинам, что и установка ограничения по времени. Это гарантирует, что вы будете более внимательным к деталям, а следовательно, не упустите чего-то важного. Небольшие, но частые проверки не только улучшат кодовую базу, но и помогут определить лучшие решения для каждой проблемы.

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

Продвигайте культуру проверок кода. Это оказывает огромное влияние не только на качество продукта, который вы создаете, но и улучшает комьюнити, делая его более сплоченным и эффективным.

В одиночку мы можем сделать так мало; вместе мы можем сделать так много

Хелен Келлер

Спасибо за внимание!

24+