Рецензирование кода, обзор кода, ревизия кода (англ. code review) или инспекция кода (англ. code inspection) — систематическая проверка исходного кода программы с целью обнаружения и исправления ошибок, которые остались незамеченными в начальной фазе разработки. Целью обзора является улучшение качества программного продукта и совершенствование навыков разработчика.
К очевидным плюсам этой практики можно отнести:
- Улучшается качество кода
- Находятся «глупые» ошибки (опечатки) в реализации
- Повышается степень совместного владения кодом
- Код приводится к единому стилю написания
- Хорошо подходит для обучения «новичков», быстро набирается навык, происходит выравнивание опыта, обмен знаниями.
Для ревью подходит любой код. Однако, review обязательно должно проводиться для критических мест в приложении (например: механизмы аутентификации, авторизации, передачи и обработки важной информации — обработка денежных транзакций и пр.). Также для review подходят и юнит тесты, так как юнит тесты — это тот же самый код, который подвержен ошибкам, его нужно инспектировать также тщательно как и весь остальной код, потому что, неправильный тест может стоить очень дорого.
Вообще, ревью кода должен проводиться в совокупности с другими гибкими инженерными практиками: парное программирование, TDD, CI. В этом случае достигается максимальная эффективность ревью. Если используется гибкая методология разработки, то этап code review можно внести в Definition of Done фичи.
- Сначала design review — анализ будущего дизайна (архитектуры).Данный этап очень важен, так как без него ревью кода будет менее полезным или вообще бесполезным (если программист написал код, но этот код полностью неверен — не решает поставленную задачу, не удовлетворяет требованиям по памяти, времени). Пример: программисту поставили задачу написать алгоритм сортировки массива. Программист реализовал алгоритм bogo-sort, причем с точки зрения качества кода — не придраться (стиль написания, проверка на ошибки), но этот алгоритм совершенно не подходит по времени работы. Поэтому ревью в данном случае бесполезно (конечно — это утрированный пример, но я думаю, суть ясна), здесь необходимо полностью переписывать алгоритм.
- Собственно, сам code review — анализ написанного кода. На данном этапе автору кода отправляются замечания, пожелания по написанному коду. Также очень важно определиться, за кем будет последнее слово в принятии финального решения в случае возникновения спора. Обычно, приоритет отдается тому кто будет реализовывать код (как в scrum при проведении planning poker), либо специальному человеку, который отвечает за этот код (как в google — code owner).
Самое главное при проведении review — это использование полученного результата. В результате review могут появиться следующие артефакты:
- Описание способа решения задачи (design review)
- UML диаграммы (design review)
- Комментарии к стилю кода (code review)
- Более правильный вариант (быстрый, легкочитаемый) реализации (design review, code review)
- Указание на ошибки в коде (забытое условие в switch, и т.д.) (code review)
- Юнит тесты (design review, code review)
что именно происходит на code review сильно зависит от компании. К примеру, там где я работаю сейчас, ревью делает любой разработчик, который свободен в это время. Он проверяет следующее:
- в коде нет конфиденциальной информации, такой как пароли (они должны быть в конфигах), имена разработчиков или чего то подобного
- в коде нет явных глупостей: бесконечных циклов, "заката солнца вручную".
- код понятен (хотя этим иногда пренебрегают, а иногда нужно объяснить свое решение).
- в коде нет бекдоров/вирусов и подобного.
- стиль. Но тут все очень индивидуально и некоторые считают, что их чувство прекрасного лучше, чем оффициальные гайды.
Как происходит сам процесс:
- разработчик делает себе ветку и там пишет код. Код обязательно пушится, но не мерджится в основную ветку.
- делается дифф изменений и отправляется на специальный адрес внутренней рассылки. Также в письмо добавляет краткое объяснение "что и почему сделано", буквально одно-два предложения.
- другие разработчики просматривают почту или специальный внутренний сайт, на который диффы попадают автоматом через почту (сейчас планируем сделать, что бы они вытягивались с гита автоматом).
- Если другие согласны с кодом, отправляют "+1", если нет - минус и объяснение почему.
- если пплюс получен и пройдено тестирование, код мерждится в мастер.
- когда все выкатывается в релиз, специальный код проверяет, что на каждый мердж был получен +1.