Что такое Code Review, как это фактически происходит?

#инспекция_кода #agile

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

Ответы

Ответ 1

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


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


Как происходит сам процесс:


разработчик делает себе ветку и там пишет код. Код обязательно пушится, но не мерджится
в основную ветку.
делается дифф изменений и отправляется на специальный адрес внутренней рассылки.
Также в письмо добавляет краткое объяснение "что и почему сделано", буквально одно-два
предложения. 
другие разработчики просматривают почту или специальный внутренний сайт, на который
диффы попадают автоматом через почту (сейчас планируем сделать, что бы они вытягивались
с гита автоматом).
Если другие согласны с кодом, отправляют "+1", если нет - минус и объяснение почему.
если пплюс получен и пройдено тестирование, код мерждится в мастер.
когда все выкатывается в релиз, специальный код проверяет, что на каждый мердж был
получен +1.


Ответ 2

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

Скажем, на первой моей работе обзор кода выполнялся так: разработчики собирались
вместе и поочередно смотрели код каждого из них, в случае нахождения тех или иных проблем
критиковали его, что-то предлагали для улучшения и всячески спорили. Такой подход с
одной стороны несколько сложноват - нужно всех собрать, выслушать мнение каждого, потратить
время на обсуждение, но с другой стороны позволяет каждому расти профессионально (в
споре рождается истина как известно) и вообще довольно демократичен.
 На другой работе ревью не было вовсе (что наверное неправильно), на еще одной работе
ведущий разработчик смотрел код, попадающий в коммит и самолично принимал решение относительно
правильности/неправильности тех или иных его участков.


Ответ 3

Любая. Кто как может, так и проводит.

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

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


Ответ 4

А давайте переведем этот термин на русский, что бы было понятнее, о чем вообще идет
речь. Итак, что такое "Code Review" или же "Пересмотр исходного кода"? Это когда Вы
или Ваши коллеги пересматриваете исходный код и начинаете думать, как его улучшить
и нет ли в нем опасных мест, ошибок и выискиваете способы улучшения его качества.

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


Ответ 5

Вот у @KoVadim круто!

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

Поэтому практически все ревью кода сводились к абсолютно неформальному и нерегулярному
-- "слушай, что-то мой (или твой) кусок фигово работает, давай посмотрим..."