Что такое код-ревью и зачем оно нужно
Код-ревью, или просмотр кода — это процесс, в ходе которого один или несколько разработчиков просматривают исходный код, написанный другим разработчиком. Обычно это происходит перед тем, как новый код будет добавлен в основную ветку проекта. Представьте, что вы написали главу книги. Прежде чем отправить ее в печать, вы даете прочитать ее коллеге или редактору. Код-ревью выполняет похожую функцию в мире программирования.
Основная задача код-ревью — найти проблемы до того, как они попадут в рабочую версию программы. Это могут быть ошибки, недочеты в логике, проблемы с производительностью или безопасностью. Кроме того, это отличный способ обменяться знаниями внутри команды и убедиться, что весь код соответствует принятым стандартам.
Почему это так важно? Найти и исправить ошибку на ранней стадии разработки гораздо дешевле и проще, чем когда она уже попала к пользователям или вызвала сбой в системе. Код-ревью помогает предотвратить многие такие проблемы.
Основные цели код-ревью
Код-ревью — это не просто поиск ошибок. У этого процесса есть несколько важных целей, которые делают его неотъемлемой частью современной разработки.
Поиск ошибок
Это самая очевидная цель. Свежий взгляд со стороны часто замечает то, что упустил сам автор. Это могут быть логические ошибки, неправильное использование синтаксиса языка в сложных случаях или проблемы, связанные со взаимодействием нового кода с уже существующим.
Улучшение качества
Ревью помогает сделать код более читаемым, понятным, поддерживаемым. Ревьюер может предложить лучшие названия для переменных и функций, более элегантные алгоритмические решения или способы упростить сложную логику. Код, который легко читать и понимать, проще развивать и поддерживать в будущем.
Обмен знаниями
В процессе ревью младшие разработчики учатся у старших, видя примеры более опытных решений и подходов. Старшие разработчики глубже погружаются в различные части проекта, понимая, кто над чем работает и как устроены разные модули. Это способствует распространению знаний о кодовой базе внутри команды.
Повышение безопасности
Ревьюер может выявить потенциальные уязвимости, связанные с обработкой пользовательского ввода, работой с данными, использованием сторонних библиотек и другими аспектами, которые могут стать источником проблем.
Чек-лист для проверки кода: от стиля до безопасности
Итак, вы получили запрос на код-ревью. С чего начать? Вот примерный чек-лист, который поможет вам структурировать проверку. Проходя по этим пунктам, вы сможете охватить большинство важных аспектов.
- Стиль и форматирование:
- Соответствует ли код стандартам кодирования проекта? Проверьте отступы, использование пробелов или табуляций, расстановку скобок.
- Правильно ли названы переменные, функции, классы? Имена должны быть понятными и отражать назначение элемента.
- Соответствует ли структура файлов и папок принятой в проекте?
- Читаемость и понятность:
- Легко ли понять, что делает этот код, прочитав его сверху вниз?
- Не слишком ли сложна логика в отдельных функциях или блоках? Возможно, стоит разбить ее на более мелкие части.
- Достаточно ли комментариев там, где логика неочевидна? Не слишком ли много избыточных комментариев, которые дублируют очевидное?
- Логика и функциональность:
- Правильно ли реализована требуемая функциональность? Соответствует ли код поставленной задаче?
- Учтены ли граничные случаи? Что происходит при пустых входных данных, нулевых значениях, крайних пределах допустимых диапазонов?
- Нет ли очевидных логических ошибок или дыр?
- Насколько эффективно используется язык и фреймворки? Нет ли избыточного или неоптимального кода?
- Обработка ошибок:
- Как код обрабатывает возможные ошибки, исключения или некорректные данные?
- Ловятся ли ожидаемые исключения?
- Понятны ли сообщения об ошибках в логах или для пользователя, если это применимо?
- Корректно ли освобождаются ресурсы, если возникла ошибка?
- Тесты:
- Написаны ли автоматические тесты для нового кода?
- Покрывают ли тесты основные сценарии использования и граничные случаи?
- Проходят ли все существующие тесты после добавления нового кода?
- Производительность:
- Нет ли очевидных узких мест, которые могут привести к снижению производительности? Например, циклы в циклах, избыточные запросы к базе данных в цикле.
- Эффективно ли используются структуры данных и алгоритмы?
- Безопасность:
- Проверяются ли входные данные от пользователя? Нет ли риска инъекций или других атак?
- Правильно ли обрабатываются конфиденциальные данные? Не попадают ли они в логи или открытый доступ?
- Используются ли актуальные версии библиотек и фреймворков без известных уязвимостей?
- Документация:
- Обновлена ли внутренняя документация или комментарии, если изменялось поведение публичных функций или модулей?
- Если требуется, обновлена ли внешняя документация для пользователей API или других систем?
Этот список может показаться длинным, но со временем и опытом прохождение по нему станет быстрее. Главное — подходить к каждому ревью внимательно, с пониманием того, что вы ищете.
Советы по организации эффективного код-ревью
Хорошее код-ревью — это не только прохождение по чек-листу, но и правильная организация самого процесса. Вот несколько советов, как сделать ревью более продуктивным и приятным для всех участников.
- Делайте ревью небольшими порциями. Гораздо проще и быстрее просмотреть 50–100 строк, чем 500 или 1000. Разработчику стоит разбивать свою работу на небольшие, логически завершенные части, и отправлять их на ревью по отдельности.
- Будьте конструктивны и вежливы. Фокусируйтесь на коде, а не на авторе. Объясняйте, почему вы предлагаете то или иное изменение. Предлагайте альтернативные решения, а не просто указывайте на проблему. Помните, что ваша цель — помочь улучшить код и поделиться опытом, а не критиковать.
- Убедитесь, что понимаете контекст. Прежде чем погружаться в строки кода, разберитесь, какую задачу он решает. Прочитайте описание запроса на слияние, посмотрите связанные задачи или обсуждения. Понимание цели поможет вам оценить правильность реализации.
- Не спорьте до бесконечности по мелочам. Если вы видите стилевое нарушение или мелкий недочет, который не влияет на логику или производительность, но не можете прийти к согласию, возможно, стоит оставить это как рекомендацию или решить вопрос быстрее, не блокируя слияние кода. Главное — функциональность, корректность и отсутствие критичных ошибок.
Примеры автоматизации процесса код-ревью
Многие рутинные проверки из нашего чек-листа можно автоматизировать. Это сэкономит время ревьюеров и позволит им сосредоточиться на более сложных аспектах, таких как логика и архитектура.
Существуют различные инструменты для автоматизации.
Линтеры
Проверяют код на соответствие стандартам кодирования, находят потенциальные ошибки и подозрительные конструкции. Например, ESLint для JavaScript, Pylint или Flake8 для Python, Checkstyle для Java. Они могут проверить правильность расстановки отступов, использование кавычек, длину строк, неиспользуемые переменные и многое другое.
Форматеры
Идут дальше линтеров. Они не только указывают на стилевые нарушения, но и автоматически исправляют их, приводя код к единому формату. Например, Prettier для фронтенда, Black для Python, gofmt для Go. Использование форматеров снимает большую часть вопросов по стилю во время код-ревью.
Анализаторы статического кода
Проводят более глубокий анализ кода без его выполнения. Они могут находить более сложные проблемы, такие как потенциальные ошибки выполнения, уязвимости безопасности, проблемы с производительностью или сложностью. Это, например, SonarQube, Bandit для Python, FindBugs для Java.
Эти инструменты часто интегрируются в процесс разработки. Они могут запускаться при каждом сохранении файла, при попытке отправить код в репозиторий или автоматически при создании запроса на слияние. Если автоматические проверки находят ошибки или стилевые несоответствия, они могут даже блокировать возможность слияния кода до их исправления.
Использование автоматизации не заменяет человеческое ревью, но делает его гораздо эффективнее, избавляя от необходимости вручную проверять базовые вещи.