Code Review — зачем и как использовать в команде

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

Сode Review — что это и как устроен процесс

Code Review — это процесс обязательной проверки любого фрагмента кода. Независимо от объема и цели, каждый кусочек кода должен пройти код ревью в той или иной степени, прежде чем он будет интегрирован в проект. Обычно его проводят перед тестированием продукта. Разница между Code Review и тестированием в том, что задача тестировщика — найти ошибки, а ревьюера — понять логику разработки и увидеть в ней несоответствия и слабые места. 

Зачем нужна проверка кода

Код-ревью помогает: 

• Привести код «в боевую готовность»: найти ошибки и недочеты, которые помешают корректной работе сайта или приложения.
• Улучшить и «причесать»: привести каждый кусок кода к единому стилю, сделать его понятным и легко читаемым для других разработчиков.
• Защититься от уязвимостей: убедиться, что код отвечает требованиям безопасности и не перегружает оперативную память ОС. 
• Обмениваться опытом: контролировать и направлять джуниоров или стажеров, помогая им улучшить навыки.
• Подстраховаться: если разработчик поделится своей частью кода с коллегой, тот сможет подхватить его в случае увольнения или отпуска.  

Кто проводит 

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

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

Как это выглядит

Процесс Code Review состоит из этапов: 

1. Подготовка. Сначала разработчик создает Pull Request или Merge Request (зависит от конкретного инструмента для ревью) — чтобы предложить изменения в репозитории, где его смогут увидеть другие разработчики. Отдельно можно прописать задачу и логику решения, какие изменения были внесены в код и дать комментарии к наиболее сложным фрагментам.
2. Основной этап Code Review — это анализ качества кода. Под качеством кода подразумевается его чистота, читаемость, поддерживаемость и эффективность. Ревьюер проверяет, насколько код соответствует стандартам компании по стилю, объему, синтаксису и другим требованиям.
3. Рекомендации. Проверив код, ревьюер оставляет комментарии для разработчика: что можно убрать, добавить или улучшить. 
4. Внесение изменений. Разработчик берет в работу рекомендации ревьюера и отписывается по результатам. После этого код могут снова отправить на ревью или передать для тестирования.  

Чек-лист, по которому идет ревьюер в процессе проверки: 

1. Читаемость: Проверить, легко ли понять код. Он должен быть чистым, понятным, с осмысленными названиями переменных и функций. Это важно для будущего сопровождения кода другими разработчиками.
2. Логика и функциональность: Убедиться, что код делает именно то, что должен, и что логика работы корректная. Важно избежать багов и неправильной работы программы.
3. Производительность: Оценить эффективность кода. Нужно убедиться, что алгоритмы и структуры данных оптимальны для быстроты работы, особенно если код будет использоваться в масштабируемых системах.
4. Безопасность: Проверить уязвимости, такие как SQL-инъекции, неправильное управление доступом или хранение данных. Это важно для защиты данных и систем от хакеров.
5. Тестирование: Убедиться, что код покрыт тестами, и они выполняются корректно. Это помогает убедиться, что новые изменения не ломают старую функциональность.
6. Обработка ошибок: Проверить, как код обрабатывает исключения и ошибки. Важно, чтобы система могла продолжать работать или корректно сообщать об ошибках, не выдавая неконтролируемые сбои.
7. Архитектура: Оценить, насколько структура кода соответствует общей архитектуре приложения. Это нужно для поддержания модульности и масштабируемости проекта.
8. Зависимости: Проверить, не используются ли устаревшие или небезопасные внешние библиотеки, и не вводит ли код лишних зависимостей. Это важно для безопасности и упрощения будущих обновлений.
9. Документация: Убедиться, что код и его функциональность документированы. Это помогает другим разработчикам и будущим вам быстро понять, как работает программа и как ее поддерживать.

Итогом ревью будут: 

• Список критических ошибок и недочетов, которые нужно исправить. 
• Рекомендации по улучшению. 
• Вопросы для разработчика — если что-то в коде вызывает сомнения.  

Инструменты для Code Review

Существуют десятки онлайн-сервисов для хранения и обмена репозиториями, а также Code Review — вручную и при помощи ботов. Вот самые популярные из них: 

GitHub

Open source-сервис (то есть с открытым исходным кодом) для всех этапов разработки, где Code Review доступен в бесплатной и платных версиях. Для ревью используются Pull Request — то есть запросы на слияние изменений в коде с основной веткой. В них также коротко описывают суть и причины изменений.

Из минусов — отсутствие локальной версии и поддержка только тех git-репозиториев, которые размещены на этом ресурсе.  Чтобы работать с CI/CD, понадобится специальный инструмент — GitHub Actions. Также можно расширить функционал при помощи маркетплейса. 

GitLab

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

В отличие от GitHub, инструменты для работы с CI/CD уже встроены в сервис, а число пользователей с разными доступами в бесплатной версии не ограничено. Вместо Pull здесь используют Merge Request — запросы на слияние веток. 

Bitbucket

Сервис, который также можно использовать в облаке или на сервере. Важное отличие: в бесплатной версии доступны частные закрытые репозитории, но только для пяти пользователей. Есть интеграции с Jira, Trello и другими популярными IT-сервисами. Для Code Review используют Pull Request. 

Из минусов — отсутствие многофакторной аутентификации и встроенного редактора кода. 

Рекомендации по организации Code Review

Вот советы, которые помогут провести код-ревью с максимальной пользой: 

1. Введите единые стандарты. В этом помогут Code Style и другие рекомендации по написанию кода, которыми будут пользоваться все разработчики. Тогда у ревьюера будут четкие критерии для проверки и оценки. 

2. Оценивайте код, а не разработчика. Задача ревьюера — докопаться до логики и донести суть проблемы, а не критиковать коллег. Поэтому комментарии должны быть дружелюбными, четкими и по существу. 

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

4. Не придирайтесь к мелочам. Основное внимание в процессе код-ревью нужно уделять критическим ошибкам и уязвимостям, которые приведут к сбоям в работе. Бывает, что ревьюеру и вовсе не к чему придраться: код написан правильно, за исключением мелких недочетов. Тогда можно ограничиться рекомендациями и не выискивать ошибки «ради галочки». 
5. Не забывайте хвалить. Задача ревьюера — не только критика, но и поддержка. Важно подмечать удачные решения и сообщать об этом автору, чтобы он понимал, что в команде его ценят. 

Что касается самих разработчиков, которые отправляют код на ревью, то главное правило — делать Pull Request или Merge Request как можно короче: 200-500 измененных строк кода. Иначе ревьюер потратит много времени только на то, чтобы прочитать запрос, и сроки проверки сильно затянутся. 

Идеальный код после ревью — это тот, который: 

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

Преимущества код-ревью

1. Код становится лучше: и в плане читаемости, и в плане архитектуры. Во-первых, благодаря ревьюеру, во-вторых — самому разработчику: зная, что код будут проверять, он будет внимательнее в процессе работы. 
2. Код пишется в едином стиле: разработчики знают, как оформить ту или иную строку и функционал и понимают, чего от них ждет ревьюер — потому что все работают по единым стандартам. Готовый код хорошо понятен всем разработчикам, включая тех, что будут работать с ним позже. 
3. Повышается безопасность: код не содержит очевидных уязвимостей, которые могут навредить конечному продукту и его пользователям.
4. Разработчики обмениваются опытом: причем не только от ревьюера к автору кода, но и наоборот. В итоге члены команды перенимают лучшие решения друг у друга, а новички учатся быстрее. 

Недостатки код-ревью

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

Когда и кому нужен review кода?

Код-ревью — это важный и необходимый инструмент в любом процессе разработки.

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

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

Без него невозможно гарантировать стабильность и поддерживаемость проекта в долгосрочной перспективе.

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