>> Какой код ревьювится? (весь/отдельные компоненты или изменения/другой вариант)
В идеале нужно ревьювить всё, на практике получается просматривать только изменения.
часто новая функциональность может потребовать рефакторинг, задача ревьювера — определить, надо ли это делать сейчас вообще.
>> Какие используете инструменты?
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, партены проектирования
— не желательные антипартены, то есть как мы не делаем, как нельзя
— договоренности по проекту, это делаем в модулях, это выносим в плагины и т.п…
Идея в том, что проект должен быть разработан так, как будто работает один человек. Всё должно быть по полочкам и в одном стиле.
как-то так)
