Что такое code review и когда оно требуется?

Можно написать код. Можно отредактировать уже написанный код. Можно полностью переписать код с нуля. С кодом вообще можно сделать много всего.

Но какой в этом толк, если код существует в своей собственной «эхо-камере»? Его видит, пишет и редактирует один и тот же человек.

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

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

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

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

Только так код может оставаться «свежим» и эффективным, а приложения на его основе — безопасными и производительными.

cloud

Что такое code review?

Code review — это процесс проверки кода одним или несколькими разработчиками для выявления ошибок, улучшения качества и повышения читаемости.

Какие бывают виды code review?

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

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

Формальное ревью (Formal Review)

Формальное ревью — это строгий процесс проверки кода с четко установленными этапами.

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

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

Кот-ревью (источник: Pikabu)

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

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

1. Разработка. Один из разработчиков завершил работу над новым модулем аутентификации и отправил код на ревью через систему контроля версий Git на GitHub.

2. Анализ. Группа ревьюеров, состоящая из двух senior-разработчиков и одного специалиста по безопасности, получает уведомление о Pull Request в GitHub. После этого они исследуют код, проверяя его логическую корректность и читаемость, соответствие стандартам безопасности (например, устойчивость к SQL-инъекциям и XSS-атакам).

3. Обсуждение. После индивидуальной проверки ревьюеры созваниваются с разработчиком кода в Zoom и дают ему обратную связь о найденных проблемах.

4. Документирование. Все замечания указываются в комментариях к Pull Request в репозитории на GitHub и фиксируются на канбан-доске в системе управления задачами Jira. Например, некоторые RESTFul-запросы помечаются ревьюерами как уязвимые для SQL-инъекций с рекомендацией использовать параметризованные запросы.

5. Исправление. Разработчик вносит правки, обновляет Pull Request в репозитории на GitHub и отправляет его на повторное ревью. После этого процесс ревью циклически повторяется продолжается до тех пор, пока код не будет одобрен.

6. Одобрение. Когда группа ревьюеров окажется удовлетворена всеми внесенными правками в Pull Request, код сливается в основную ветку репозитория.

Таким образом, с помощью формального ревью проводится валидация нового кода в репозитории проекта.

Неформальное ревью (Unformal Review)

Неформальное ревью — это менее строгий и более свободный процесс проверки кода со слабо установленными этапами. Как правило, это:

• быстрое обсуждение кода в чате или на встрече,
• личная демонстрация кода коллеге,
• получение от экспертов ответов на технические вопросы.

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

Говоря проще, неформальное ревью — это скорее обращение за советом или экспертным мнением к коллеге, нежели полноценный анализ кода третьим лицом. Это своего рода обмен знаниями.

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

• Перекрестное ревью (Over-the-Shoulder Review). Один разработчик показывает свой код другому в режиме реального времени — как онлайн, так и оффлайн. Это может быть трансляция в видеоконференции, шеринг кода (например, VS Code Live Share), отправка сообщения в чат или даже обычный поворот монитора к коллеге за соседним столом.

• Внеочередное ревью (Ad-hoc Review). Разработчик просит коллегу посмотреть код в любое удобное время, отправив ссылку на файл или оставив сообщение в чате. Говоря проще, это менее навязчивый способ спросить совета. Что-то вроде: "Я тут написал обработчик запросов, но что-то вылетает ошибка. Можешь глянуть, когда будешь свободен?".

• Групповое ревью (Unstructured Team Review). Код обсуждается на встрече команды, но без формальных процедур. По сути, это совместный разбор кода, направленный на его улучшение. Ну и разумеется обмен опытом и знаниями тоже не исключен.

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

То есть во время неформального ревью разработчик вообще может усомниться в компетентности ревьюеров и полностью отвергнуть все их советы.

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

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

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

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

• Оперативные исправления. Вместо долгого обмена комментариями разработчик может сразу внести правки после устного обсуждения.

Таким образом неформальное ревью дополняет формальное, сокращая время на внесение исправлений.

Парное программирование (Pair Programming)

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

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

Соответственно, у каждого разработчика есть своя роль — все как в ралли:

• Водитель (Driver). Пишет код, сосредоточен на синтаксисе и деталях реализации.

• Штурман (Navigator). Следит за логикой, ищет ошибки, предлагает улучшения и думает на несколько шагов вперед.

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

Само по себе парное программирование делится на два вида:

• Строгое (Strong Style Pairing). Штурман принимает ключевые решения, а водитель просто пишет код. Это особенно хорошо работает, когда один из участников более опытный.

• Обычное (Loose Pairing). Оба принимают ключевые решения, чередуя роли по мере необходимости.

Несмотря на то, что парное программирование практикуется редко, у него есть несколько преимуществ над классическим код-ревью:

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

• Глубокий анализ. Второй разработчик не просто проверяет код, а принимает непосредственное участие в его создании.

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

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

Автоматизированное ревью (Automated Review)

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

Как правило, инструменты анализа запускаются автоматически по триггеру. Например, после завершения компиляции, отправке коммита или при создании Pull Request.

После этого инструмент (или цепочка инструментов) автоматически анализирует код, проводит его тестирование (например, юнит-тесты) и выдаёт отчет. Более того, автоматические инструменты могут самостоятельно выполнять слияние изменений с основной веткой, если код прошёл все стадии проверки.

Автоматизированное ревью является частью DevOps и активно применяется при создании CI/CD-конвейеров для анализа кода перед его развертыванием в продакшене.

Автоматический анализ кода можно поделить на два вида — для каждого применяются свои инструменты:

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

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

Когда требуется code review?

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

Внедрение автоматического тестирования стало стандартом для современной разработки, начиная с веб-сайтов на JavaScript и заканчивая системными библиотеками на C++.

Тем не менее, для мелких незначительных изменений ревью кода можно не проводить. Например, для правок комментариев, форматирования кода или изменения текста в UI.

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

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

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

Основные этапы проведения code review

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

Подготовка к ревью

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

Соответственно, у разработчика есть цели проверки и примерный план ее проведения. По крайней мере в общих чертах.

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

В противном случае цели проверки окажутся недостигнутыми и в коде останутся критические ошибки.

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

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

Когда разработчик готов к ревью, он сообщает об этом ревьюерам — через чат, через Pull Request или просто устно.

Анализ кода и выявление ошибок

Код изучается участниками ревью в течение некоторого времени. В ходе изучения подготавливаются правки в различных форматах — предложения исправлений в IDE, комментарии в чате, устные замечания, отчеты тестирования.

На самом деле формат правок зависит от тех средств, которые принято использовать в команде разработке. Тут все уникально для каждого проекта.

Обсуждение правок и рекомендаций

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

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

Документирование и подготовка задач для исправления

Все найденные недочеты должны быть каким-то образом зафиксированы и явно помечены. На основе этого готовится список задач для исправления. Часто для этого используются канбан-доски или таск-менеджеры. Например, Jira, Trello, GitHub Issues.

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

Канбан-доска в таск-менеджере Trello (источник: РБК Тренды)

Даже если это одиночный разработчик, занимающийся домашним проектом, задачи могут фиксироваться в Блокноте (возможно даже не в программе Windows, а в настоящем блокноте с ручкой). Хотя, конечно, никто не запрещает держать задачи в голове.

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

Внесение исправлений и финальное утверждение

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

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

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

Инструменты для code review

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

• Системы контроля версий. Большинство облачных платформ для хранения кода, которые используют системы контроля версий (чаще всего Git), предоставляют инструменты для ревью — просмотра кода, внесения изменений и комментирования сниппетов.

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

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

• Автоматизированные тесты. Статически проверенный код проверяется во время выполнения. Чаще всего для этого используются уникальные для каждого языка библиотеки юнит-тестирования.

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

GitHub / GitLab / Bitbucket

GitHub, GitLab, Bitbucket — это облачные платформы для совместного размещения кода, в основе которых лежит система контроля версий Git.

На каждой из этих платформ есть соответствующий инструмент для удобного проведения код-ревью. В GitHub и Bitbucket он называется Pull Request, а в GitLab — Merge Request.

Просмотр изменений кода в GitHub (источник: Awesome Code Reviews)

Работает она следующим образом:

1. Разработчик создает Pull/Merge Request, в котором можно фиксировать изменения код, комментарии участников и историю коммитов.

2. Ревьюеры оставляют комментарии и общие замечания в строках кода.

3. По завершении обсуждения кода ревьюеры могут выполнить Approve (принять все изменения) или Request Changes (запросить дополнительные исправления).

Ну и конечно же каждая из платформ предоставляет инструменты для построения CI/CD-конвейеров, отвечающих за запуск автоматических тестов:

• GitHub Actions

• GitLab CI/CD

• Bitbucket Pipelines

Собственно, GitHub, GitLab и Bitbucket можно считать основными инструментами для проведения ревью. Какой инструмент выбрать — зависит от предпочтений команды разработчиков. В общих чертах они похожи, но в нюансах отличаются.

Crucible

Atlassian Crucible — это специализированный инструмент исключительно для проведения код-ревью, способный работать с различными системами контроля версий: Git, SVN, Mercurial, Perforce.

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

И разумеется, Crucible глубоко интегрируется с другим продуктом компании — системой управления проектами Jira, которая поддерживает канбан-доски.

Просмотр комментариев ревью в Crucible

Crucible не является облачной платформой. В отличие от GitHub, GitLab и Bitbucket это локальное решение, которое устанавливается либо на сервер компании, либо в частное облако.

Поэтому с одной стороны порог входа в Crucible выше — система требует настройки и администрирования со стороны команды. С другой стороны, Crucible позволяет организациям выстраивать собственные политики безопасности и конфиденциальности данных.

Другие инструменты

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

Например, в С/C++ есть Valgrind для отладки использования памяти. В Java есть JProfiler и YourKit для профилирования и диагностики приложений, а еще Checkstyle и PMD для проверки синтаксиса. В Python есть PyInstrument для анализа производительности, а также Pylint и Flake8 для анализа качества кода.

Как правило инструменты автоматического тестирования запускаются фреймворками для организации CI/CD-конвейеров — GitHub Actions, GitLab CI, CircleCI, Jenkins.

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

Лучшие практики и советы по code review

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

Вносите атомарные изменения

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

В какой-то степени это напоминает «Принцип единственной ответственности» (Single responsibility principle, SRE) в SOLID. Каждое ревью отвечает только за одну функциональность, на анализе которое фокусируются все участники — проверяют, обсуждают, вносят правки.

Автоматизируйте все, что можно

Средства автоматизации позволяют снизить человеческий фактор во время проверки кода. Статические анализаторы, линтеры и юнит-тесты находят ошибки быстрее и точнее, чем человек.

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

Проверяйте код, а не разработчика

Code Review — это о коде, а не о личностях. Критика должна быть направлена в сторону кода, а не его автора. Важно соблюдать профессиональную этику и беспристрастность, используя мягкие формулировки. Soft Skills и конструктивность!

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

Хорошее ревью мотивирует и улучшает командную работу. А вот плохое вызывает стресс и конфликты.

Будьте внимательны к архитектуре и логике

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

Поэтому важно уделять особое внимание структуре кода. Идеально написанный алгоритм — ничто в ужасно спроектированном приложении.

Используйте чек-листы для ревью

Чтобы не проводить ревью вслепую, можно подготовить чек-лист — список ключевых аспектов, на которые необходимо обратить внимание при проверке кода.

Вот пример простейшего чек-листа:

• Насколько код читабельный?

• Насколько код поддерживаемый?

• Есть ли в коде дублирования?

• Покрыт ли код тестами?

• Соответствует ли код выбранным архитектурным принципам?

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

Обсуждайте сложные изменения устно

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

Хотя опять же, все зависит от типа обсуждения. Если речь идет об общих архитектурных решениях, то устная дискуссия может быть удобнее. А если обсуждение затрагивает конкретные участки кода, то в сообщениях и комментариях легче показывать примеры.

Код должен быть понятен без пояснений

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

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

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

Подготовили для вас выгодные тарифы на облачные серверы

Заключение

Code review — это набор практик для проверки качества кода с последующим внесением изменений. Ревью начинается с анализа синтаксиса и архитектуры, а заканчивается тестированием производительности и безопасности.

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

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