👀 Повышаем качество код-ревью: 7 полезных советов

Полный контрольный список проверки кода

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

1. Проверьте требования к функциям

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

Чтобы проверить требования к функциям, спросите себя:

• Есть ли недостающая функциональность?
• Есть ли плохо реализованные функции?
• Могут ли они добавить какие-либо связанные функции, которые пожелает пользователь?

2. Оцените удобочитаемость

Чтобы проверить требования к функциям, спросите себя:

• Может ли код поместиться на экране ноутбука (14 дюймов) или на экране настольного компьютера (22-24 дюйма)?
  
• Говорит ли код сам за себя и передает ли его цель?
• Насколько ясен и лаконичен код?
• Есть ли в коде непонятные выражения?
  
• Можете ли вы различить роль конкретных функций, методов или классов?
• Разбил ли разработчик код на простые для понимания блоки?
  

3. Проверка сопровождаемости

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

Задайте себе эти вопросы, чтобы оценить сопровождаемость кода:

• Легко ли тестировать и отлаживать код?
• Можете ли вы настроить код для быстрого изменения значений данных?
• Код привязан к другой системе или устаревшей программе?
• Полагается ли код на функции или технологии, от которых вы хотите отказаться?

4. Проверьте наличие уязвимостей в системе безопасности

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

• Используются ли в коде устаревшие инструменты или инструменты с известными проблемами безопасности?
• Если бы вы хотели украсть данные или получить доступ к системе, какими уязвимостями вы бы воспользовались?
• Используется ли код аутентификации и авторизации для обеспечения безопасности?
• Проверяется ли ввод пользователя?
• Надежно ли код хранит пользовательские данные?
• Защищает ли код P2 или другие данные, связанные с GDPR?

5. Учитывайте скорость и производительность

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

Задайте себе несколько вопросов, чтобы оценить скорость и производительность:

• Содержит ли код неэффективные конкатенации строк, ведение журнала или присвоения объектов?
• Можете ли вы увидеть повторяющийся код, который вам не нужен?
• Будет ли программа негативно влиять на производительность системы в целом?
• Использует ли код плохо оптимизированные ресурсы или несколько запросов API?

6. Проверьте наличие соответствующей документации

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

Чтобы убедиться, что документация соответствует требованиям, спросите:

• Объясняет ли документация назначение кода?
• Обучает ли документация пользователя тому, как использовать код?
• Требуют ли какие-либо новые функции или изменения кода дополнительную документацию?
• Ясна ли документация и хорошо ли она написана?

7. Проверьте соглашения об именовании

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

Вы можете проверить соглашения об именовании, спросив:

• Вы просматривали имена переменных, констант, полей классов, свойств и методов?
• Названия простые и разборчивые?
• Соответствуют ли имена принятым в вашей компании правилам именования?
• Передают ли имена, что такое функция или переменная?
• Объясняют ли названия контекст или объем всей кодовой базы?

Какова цель код-ревью?

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

Обеспечение качества кода

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

Вот когда свежий взгляд со стороны помогает: это дает вам уверенность в том, что кто-то другой обнаружит проблемы в коде, пока вы готовите столь необходимый кофе (или чай).

Делитесь знаниями и улучшайте командную работу

Обзоры кода дают как рецензенту, так и автору кода возможность учиться. Например:

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

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

Улучшить безопасность

Безопасные проверки кода помогают выявлять уязвимости и недостатки безопасности в ручном или автоматизированном процессе. Нарушения безопасности могут привести к:

• Дефектам поздней стадии разработки.
• Плохому общему качеству кода.
• Ухудшению сопровождаемости с течением времени.
• Более высокому техническому долгу.
• Краже информации о пользователях.

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

Сокращение затрат на разработку

Проверка кода выявляет незначительные проблемы, которые могут перерасти в серьезные проблемы. Раннее исправление ошибок может сэкономить затраты на разработку и помочь рецензенту выявить проблемы, на которые следует обратить внимание. Когда это выгодно и познавательно, вы (буквально) не можете позволить себе пропустить ревью.

На что не стоит обращать внимание при код-ревью

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

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

Как улучшить процесс код-ревью

Теперь, когда вы знаете, на что обращать внимание при проверке кода, вы можете отточить этот процесс. Мы изложили несколько советов по улучшению процесса проверки кода:

1. Примите руководство по стилю: разрешите споры о стиле, приняв руководство по стилю кода для всей организации. Он должен не только определять поверхностные элементы, такие как правила пробелов или соглашения об именах, но также и то, как использовать возможности любого языка программирования.
2. Рассматривайте код-ревью как высокоприоритетную задачу: установите внутренние рекомендации о том, как быстро код должен проверяться.
3. Стремитесь к действенной обратной связи и наводящим вопросам: вместо того, чтобы комментировать код, спросите автора, почему он отформатировал код определенным образом или какие намерения стояли за решением. Здесь вы стремитесь к диалогу.
4. Замените «вы» на «мы». Когда вы говорите о проблеме, отформатируйте свой ответ так: «Нам нравится делать X, потому что Y». Избегайте комментариев вроде: «Здесь вы не следовали нашим рекомендациям по стилю». Напоминание разработчикам о том, что вы все работаете в одной команде, поддерживает моральный дух.
5. Опирайтесь на принципы, а не на мнения: стремитесь к объективной обратной связи, основанной на принципах кодирования. Это также обеспечивает культуру обучения для автора, чтобы лучше понять «почему» для определенной части обратной связи.
6. Сосредоточьтесь на аспектах, которые принесут наибольшую пользу: не сосредотачивайтесь на каждой возможности улучшить код во время проверки. Совершенство — это здорово, но, учитывая время и масштаб проекта, сосредоточьтесь на областях, которые окажут наибольшее влияние.

Часто задаваемые вопросы по код-ревью

У вас все еще есть несколько вопросов о правилах проверки кода или о том, на что обращать внимание при проверке кода? Нет проблем, у нас есть ответы.

В чем разница между код-ревью и проверкой кода?

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

Какие инструменты упрощают проверку кода?

1. Инструменты статического анализа кода. Статический анализ сканирует исходный код синтаксического анализа на наличие ошибок и проблем с безопасностью. Использование одного из них перед обзором может помочь вам сконцентрироваться на более сложных проблемах.
2. Подключаемые модули для исправлений. Подключаемые модули для форматирования, отладки и рекомендаций могут помочь во время проверки. Во время проверки эти подключаемые модули указывают на проблемы, которые вы могли пропустить.
3. Трекеры комментариев для проверки кода. Приложения для совместной проверки и инструменты отслеживания комментариев показывают, кто взаимодействовал с кодом и вносил в него изменения.

Какие показатели я должен иметь в виду?

Команды должны выбрать метрики или контрольные показатели разработки программного обеспечения, чтобы отслеживать эффективность проверок кода и их влияние на качество кода. Метрики также дают командам объективные показатели для структурирования проверок кода.

Следующие четыре показателя являются хорошей отправной точкой для включения в процесс обзора:

1. Время реакции: этот показатель помогает организовать совместную работу над проектами с несколькими разработчиками. Просто запишите, сколько времени требуется рецензенту, чтобы ответить на адресованный ему комментарий. Более короткое время реакции обычно означает более сплоченную команду.
2. Непроверенные PR: руководители обращаются к непроверенным PR, чтобы увидеть, как долго код ожидает экспертной оценки после его отправки. Более короткие сроки указывают на эффективный конвейер, в котором проверки кода происходят по расписанию.
3. Тщательно проверенные PR: этот показатель измеряет глубину каждого обзора кода.
4. Повторяющиеся PR: вы можете увидеть, как часто проверки кода приводят к исправлению ошибок или улучшению качества с помощью повторяющихся PR. Большое количество повторяющихся PR означает, что ваши проверки кода приводят к измеримым улучшениям.

Сколько строк кода я должен просматривать?

Для достижения наилучших результатов просматривайте не более 400 строк кода за раз. Чуть больше, и вы рискуете пропустить ошибки, логические ошибки и другие дефекты. Еще лучше, если вы можете ограничить себя 200 строками кода за раз, то вы добьетесь наибольшего успеха.