В сети появился документ с набором правил и подходов, которые практикуются в компании Google по code review: https://google.github.io/eng-practices/review/reviewer/

А вы практикуете code review в своей команде? Комментарий можно оставить к этому посту, нажав на кнопку Add a comment

3 comments

Мы начали практиковать code review через pull-request на Bitbucket меньше чем год назад. Первые впечатления были - полный восторг, команда состояла из 3 человек, параллельно велись 2 проекта. Сейчас команда увеличилась до 5 человек, параллельно ведутся 6 проектов на 2 языках. Количество pull-request-ов растёт на дрожжах. Основная проблема в том, что у каждого pull-request-а свой жизненный цикл. Баг фиксы проходят быстро, а новые фичи либо накапливаются в огромном реквесте или в длинной цепочке последовательных реквестов, которые иногда висят в списках открытых неделями. Иногда начинает раздражать, но польза для качества кода огромная.
Появилась идея использовать kanban -доску для отображения состояния pull-request-ов. Я даже нашёл плагин для bitbucket для этих целей, но с первого раза он не завёлся. Может у кого-то есть советы по управлению большим количеством pull-request-ов?
А кто проводит ревью? Вся команда вовлечена или только mid/senior инженеры ?
Adil
А кто проводит ревью? Вся команда вовлечена или только mid/senior инженеры ?
Зависит от задачи и проекта. Вовлечены все, но в разной степени. В среднем, обычно 2 ревьювера на pull-request. Старшие смотрят за младшими, младшие перепроверяют старших. Больше всего нагрузка на тимлида, он в основном и является бутылочным горлышком. Без его апрува ничего не идёт в dev бранч.