Немного живого code review

В этой статье я не буду расказывать о том что такое code review, кода и зачем это нужно и чем полезно. Про всё это уже написаны сотни статей и вы можете ознакомиться с особенностями этой практики в интернете. Сегодня я раскажу про то как мы с коллегами адаптировали этот процесс в одной фирме, в которой я работал.


Начало

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

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

В качестве хранилища git-репозиториев мы использовали Gitlab, который предоставляет довольно удобный интерфейс для просмотра кода и его комментирования. Особенно понравился подсчёт нерешённых проблем, путём "выставления больших пальцев" - на каждый баг выставляется палец вниз, после фикса выставляется палец вверх, разница подсчитывается автоматически. Так же стоит отметить возможность вставки картинок, что очень положительно сказывается на атмосфере в команде.

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


Подводные камни

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

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

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

Мы стали проводить "group code review" - когда вся команда собиралась за одним монитором или в общем месте (meeting room). Код просматривался сразу всеми членами команды, обсуждался на месте, и вердикт выносился в качестве единственного комментария. Естественно этот процесс был ограничен по времени, иначе он превращался в балаган. Это повысило общую ответственность и стало не так легко увельнуть от этого мероприятия.

Проблему с "жирным" diff'ом решили созданием ещё одной ветки - daily_sprint, в которой содержался текущий код. Это так же избавило нас от проблемы, когда на очередном ревью встречался знакомый кусок кода и кто-то говорил - "Это мы уже видели вчера или позавчера, пролистывай дальше", что понижало вероятность пропустить что-то важное.

Каждый раз после ревью ветку мерджили в sprint. Следующий diff был снова daily_sprint -> sprint. Раз в неделю просматривался diff sprint -> master, затем мердж и деплой.

Когда гитлаб не справлялся с diff'ом мы использовали SourceTree. Комментарии по прежнему выставлялись в гитлабе.


Резюме

Когда мы сдавали проект заказчикам, Сode Сlimate выставлял оценку 4.1, что вполне не плохо, учитывая что проект был довольно крупный и код толкали пять человек.

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

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


15.12.2014
Обсуждение недоступно