процесс разработки


Review Board – специализированная система для поддержки процесса рецензирования кода (code review). Изначально родилась как внутренняя разработка VMWare, но через некоторое время была передана в open source. Некоторое время назад наша команда попробовала использовать Review Board и я хочу поделиться результатами этого эксперимента.

Процесс работы

inbox.png

Основным рабочим объектом в Review Board является запрос на рецензию (review request) — diff с изменениями, авторским описанием того, зачем эти изменения нужны, предполагаемыми рецензентами и кучей необязательных атрибутов (закрытые баги, описание проведенного тестирования и т.п.). На высоком уровне работа с запросами организована наподобие электронной почты — запросы делятся на входящие и исходящие, рецензия на входящий запрос интерпретируется как ответ, на который автор запроса может в свою очередь ответить, написав комментарии. После исправления всех замечаний рецензия считается закрытой (submitted) и код имеет право быть включенным в стабильную ветку проекта. Основная задача, решаемая такой организацией обработки запросов — структурирование процесса и предотвращение потерь информации.

review.png

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

diff.png

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

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

Приятные возможности

Уведомления о новых запросах и рецензиях приходят на почту (можно отключить при желании).

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

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

post-review

Review Board предполагает, что изменения отправляются на рецензию до того, как попадают в систему управления версиями, и коммитятся только после внесения всех необходимых исправлений. Такой подход называется pre-commit review. Существует также post-commit review — изменения сначала попадают в version control, а потом рецензируются и в случае необходимости вносятся исправления.

Режим post-commit в настоящее время не учтен в пользовательском интерфейсе (обещают в одной из будущих версий). Существует, однако, скрипт post-review, автоматизирующий подготовку и заливку diff’а для уже закомиченных изменений. Скрипт на момент написания этого обзора не очень стабильный, и его, чтобы заставить работать на нашем Mercurial репозитории, пришлось немного доработать напильником.

Оценка удобства

Скорость работы. Отображение больших diff’ов существенно тормозит, но большинство страниц откликается весьма шустро. Внесение комментариев реализовано через AJAX и тоже достаточо быстро работает. Соответственно, на каждую рецензию приходится одна 10-15 секундная загрузка diff’а, и других замедляющих факторов нет, что в целом приемлемо.

Интерфейс. Визуальная часть сделана грамотно и нареканий не вызывает. На мониторах с небольшим разрешением может оказаться неудобным просмотр изменений в 2 колонки. Интерфейс построен по принципу “семь раз отмерь, один отрежь”. Любое изменение сохраняется как черновик и требует публикации для того, чтобы его увидели другие пользователи. Для длинных рецензий это абсолютно правильно, для изменения поля “description” у запроса на рецензию — совершенно излишне. Много обязательных полей, тот же description у запроса на рецензию. В целом, интерфейс можно назвать комфортным, но замедляющим работу.

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

Выводы

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

Будут ли преимущества перевешивать затраты сильно зависит от специфики конкретного проекта и конкретной команды.

Факторы, оправдывающие использование Review Board

  • Большой объем средней рецензии. Если рецензия с необходимыми отсылками к коду не умещается в один-два экрана, ее становится трудно читать в виде простого текста в почте или чате. Подсветка синтаксиса и удобное отображение комментариев в Review Board позволяют не путаться в гораздо более длинных рецензиях.

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

  • Весь или почти весь код должен пройти рецензирование из-за высоких требований к надежности, безопасности и т.п. Например, VMWare явно не страдает от расходов времени на рецензирование – оно все равно остается самым дешевым способом поиска проблем.

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

Иногда лучше обойтись чем-нибудь попроще

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

Мы, например, решили пропускать через Review Board только рецензии для изменений размером более одного-полутора экранов текста (примерно 30-45 строк diff-файла), а все более мелкое обсуждать без лишних формальностей.

Заключение

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

Next Page »