Кто практикует code-review?

Поделитесь опытом, как устроен процесс разработки?
  • Какой код ревьювится? (весь/отдельные компоненты или изменения/другой вариант)
  • Какие используете инструменты?
  • Как код попадает на review? (всегда при коммите, создаёте review request руками когда нужно проревьювить, другой вариант?)
  • Как используются результаты review?
  • Как отслеживается что замечания сделанные во время review были исправлены?
  • Вопрос задан
  • 9713 просмотров
Пригласить эксперта
Ответы на вопрос 8
«Какой код ревьювится?»
— Который не дописан полностью или в который добавляются новые возможности.

«Какие используете инструменты?»
— Насколько понял вопрос, конкретных инструментов не используется. Периодически используется копия старого проекта для сравнения.

«Как код попадает на review?»
— см. пункт 1.

«Как используются результаты review?»
— Непонятный вопрос. Результаты идут в текущий вариант проекта.

«Как отслеживается что замечания сделанные во время review были исправлены?»
— Ведётся дневник проделанных работ, дневник последующих изменений, дневник существующих багов.
Ответ написан
@cencio
Когда использовали ревью то:
-весь код(точней все изменения + тикет в Jira к которому код относился, в тикетах были не только баги, но и новые фичи) который комитился, кроме находящегося в «личном» бренче програмиста
-дифиренсы остылались ревьюверу(емейл), еслы были замечания — правились и отсылались еще раз, пока не будет добро на комит.
-есть инструменты, которые это автоматизируют, но ими не пользовались.
Ответ написан
clamaw
@clamaw
— Ревьювится дифф одного или нескольких коммитов
— Crucible (http://www.atlassian.com/software/crucible/overview).
— Автоматизация в расмках crucible
— Ревьювер оставляет замечания, они обсждаются в комментах к коду, правятся, коммитятся, добавляются в ревью и так пока не будет достигнут консенсус по всем вопросам.
— Раньше был хук на коммит в транк (без id рувью в crucible в коммит-месадже нельзя было закоммитить код), сейчас что-то аналогичное применяем в гите.
Ответ написан
gricom
@gricom
— Под ревью попадает весь код
— Используем инструмент reviewboard
— Перед любым коммитом дифф должен быть проревьюен. В reviewboard есть чекбокс «Ship it», который выставляется ревьюером, если у него нет замечаний. Если дифф не получил «Ship it», то он не может быть закоммичен
— Результатом ревью является коммит, в комментариях к которому указан id ревью. Код, к которому есть незакрытые замечания на reviewboard не может быть закоммичен. Таким образом в репозиторий попадает только тот код, в котором устранены все замечания
— Отслеживается очень просто — после устранения замечаний дифф для текущего ревью обновляется, поэтому каждый может увидеть, что его замечания учтены. Т.е. в репозиторий попадает именно тот дифф, который лежит на reviewboard.
Ответ написан
png
@png
>> Какой код ревьювится? (весь/отдельные компоненты или изменения/другой вариант)
В идеале нужно ревьювить всё, на практике получается просматривать только изменения.
часто новая функциональность может потребовать рефакторинг, задача ревьювера — определить, надо ли это делать сейчас вообще.
>> Какие используете инструменты?
redmine — в продуктах, где требуется поддержка-доработка.
задача — это целиком фича или функциональность. у задачи статусы, разработка-исполенно-ревью-тестировние-релиз-закрыта.
если в задаче косяки, статус возвращается назад в разработку. Претензии к коду в комментариях к задаче.
Когда-то использовали Redmine Code Review Plugin, но оно не прижилось

доска с магнитами:
весь проект бьется на задачи. задачи выписываются на бумажки и прилепляются к доске. что-то вроде такого:
lh3.googleusercontent.com/-69gkJdi-ZVM/TpXc7i_nA1I/AAAAAAAABPE/SctbMV08z9A/s700/doska1.jpg
(http://axshavan.blogspot.com/2011/10/3rd-day-of-agile.html) сделанные задачи попадают в столбец ревью.
их берут люди, которые делают ревью (1-2 разработчика, и делают ревью, если в задаче косяки, она опять попадает в новые.)
на бумажке пишется исполнитель и ревьювер.

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

>> Как код попадает на review? (всегда при коммите, создаёте review request руками когда нужно проревьювить, другой вариант?)
человек делает задачу, потом подходить в ревьюверу, и говорит, я сделал, проверяй меня. или вариант с доской, просто прикрепляет бумажку в нужное место.

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

>> Как отслеживается что замечания сделанные во время review были исправлены?

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

Зачем же тогда ревьювер? Очень просто — ревьювер проверяет работу, фактически решает ту же задачу в голове, проверяет алгоритмы, проверяет граничные условия алгоритмов, смотрит, конечно, и за качеством кода тоже следит. Но он ответственен только за одну задачу, а тим лид за всё + конечный результат.

+ имеет смысл ещё договориться заранее о стандартах кодирования и об ограничениях для конкретного проекта и вообще для всех проектов в целом.
где-то обговорить или описать:
— стандарты кодирования
— желательные методологии TDD, DDD, партены проектирования
— не желательные антипартены, то есть как мы не делаем, как нельзя

— договоренности по проекту, это делаем в модулях, это выносим в плагины и т.п…

Идея в том, что проект должен быть разработан так, как будто работает один человек. Всё должно быть по полочкам и в одном стиле.
как-то так)
Ответ написан
xanep
@xanep
Моя команда использует CodeCollaborator. На ревью выставляется все, перед заливкой в общую ветку. Ревью не заканчивается, пока все открытые дефекты не исправлены. Иногда дефект не исправляется немедленно, а создается отдельная задача в трекере (джире) о том, что надо что-то доработать и дефект помечается как «tracked externally» с номером заведенной задачи и код заливается. Это у нас частая практика с кодом, требующим рефакторинга, либо если дефект будет исправляться другим членом команды в рамках отдельной задачи.
У нас CodeCollaborator используется не только для ревью кода перед заливкой в депо, а и если нужно обсудить какой либо код/дизайн/текстовый документ и т.п.
Ответ написан
@pab
Какой код ревьювится?
Сделали новую фичу или пофиксили баг — на ревью попадают модули, в которых сделаны изменения.

Какие используете инструменты?
Скриптом генерится pdf-ка с diff-ом всех измененных файлов.

Как код попадает на review?
Есть свой веб-тул для формальных ревью (не только кода, ещё доков и т.п.). Всем заинтересованным рассылается письмо, выставляются даты, люди заносят свои комментарии, автор исправляет и выкладывает новую версию и снова идет ревью, когда все согласились (грубо говоря поставили галочки) — ревью закрывается.

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

Как отслеживается что замечания сделанные во время review были исправлены?
В конце ревью все участники видят, что код приведен в соответствие с выдвинутыми замечаниями, без общего согласия ревью нельзя закрыть, а без закрытия ревью тул, отслеживающий внесение изменений на главную ветку в системе контроля версий, просто не даст сделать изменения на мейне.
Ответ написан
pioneer
@pioneer
Мне в целом нравится процесс, принятый в одном из прошлых мест работы, его модификацию использую до сих пор:

* каждая фича делается в отдельном репозитории
* на каждый репозиторий разворачивается демо-сайт, который тестят тестеры
* после окончания разработки и одобрения тестерами делается дифф со свежим транком (лично я для этого юзаю rdiff, который потом заливается куда надо (на старом проекте — локальный Rietveld, на всех своих Reviewboard)
* там код ревьюится кем-то ключевым, кто имеет право коммитить в транк, либо просто перекрестно друг друга ревьюим
* если все ок, то в транк
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы