Comments 16
У меня вызывают сомнение некоторые из перечисленных причин отказа от ревью.
Если ревьювер по опыту не превосходит автора, свежий взгляд все же чего-то стоит, вы не согласны? Бывают ошибки типа копипасты. Такой код компилируется. От этого только ревью спасает.
А если отказаться от ревью из-за возможных конфликтов, то конфликт может быть после коммита.
Более того, где-то даже попадалась рекомендация периодически приглашать младших участников команды поревьювить код старших - и "свежий глаз" (у самого разработчика он всё-таки замыливается), и возможность чему-то дополнительно научиться на конкретном примере.
Думаю, что стоит отказываться от код ревью, когда его эффективность начинает стремиться к 0. Я согласен, что возможно ревьюер, который по опыту не превосходит автора решения может найти какую то опечатку, но возможно стоит задуматься о том, что времязатраты на это не очень оправданы.
То же самое касается и конфликтов, если они очень сильно тормозят feature delivery, тогда, кажется, стоит пересмотреть процессы в команде.
У нас была практика назначения нескольких ревьюверов в том числе и ниже по условному уровню - чтобы учились + свежий взгляд + нельзя сбрасывать со счетом менее опытных, иногда их идеи и видение превосходит имеющиеся решения.
Практика показывает, что маленькие изменения, например текста, тоже нужно ревьюить. Времени это отнимает мало, зато избавит от дальнейших правок того же самого текста, когда найдут опечатку на проде.
интересно, но используете ли вы формальные метрики, которые можно получить автоматически при использовании соответствующих инструментов для оценки качества разрабатываемого ПО?
В код-ревью нет жестких правил о том, кто именно должен проводить проверку. Идеальный сценарий, когда ревью осуществляет более опытный коллега — например, тимлид или ведущий разработчик проекта. В реальности так выходит не всегда: часто мидл проверяет мидла.
Менее опытному нужно давать ревьювить более опытного. Во-первых, так менее опытный учится, имекя перед глазами примеры того, как конкретную задачу решают более опытные коллеги. Во-вторых, более опытные часто забывают комментировать совсем не очевидные вещи, которые очевидны для них или вообще могут нафигачить криптокода, который никто кроме них прочитать не сможет. И это, как раз, хорошая возможность поправить такой код. Если менее опытный коллега ничего не понял, это повод задуматься и сделать более понятно.
Поддерживаю и добавлю еще что решает экспертность в предметной области и личная мотивация ревьюера вносить качественные изменения в рассматриваемый код. Должность тут никак не влияет.
Представьте, например, что ведущий разработчик, который занимается разработкой нового веб движка, вынужден смотреть все коммиты джунов, которые верстают лендинг. В лучшем случае это будет бесполезная трата времени, без каких либо результатов.
Хорошее замечание, и в целом справедливое. Но есть большой минус такой проверки, это ее бесполезность для предлагаемого решения. При таком подходе мы уже преследуем другую цель - обучение младших сотрудников, потому что скорее всего единственный конструктив, который сможет привнести младший разработчик - это сказать о том, что ему что то не понятно.
Если вам хочется назначать на ревью джуна, который будет смотреть код более опытных коллег, то я бы просто добавил его как еще одного ревьюера к привычному флоу.
Gerrit, кстати, тоже неплохо подходит для организации ревью
Желательно иметь код стандарт и чек-лист реклама
Код стандарт должен содержать принятые в компании практики
Типа использовать только такой метод депеденси резолвера и почему. Какие исключения из правил. Или например не должны персональные данные пользователей утекать в логи. И т.д.
Этот набор правил должен постоянно пополняется, а код стандарт постоянно исправляться , как результат анализа часто повторяющихся, багов, рантайм факапов , замечаний ревьеров.
У ревьера должен быть чек лист что и как должно быть проверено на ревью.
Часто ревью быстрее и дешевле тестирования находит потенциальные факапы. Всё это относится к мероприятиям обеспечения качества кода. Возможно часто к ревью надо привлекать тестировщиков и аналитиков.
Да на ревью имхо надо приглашать не только старших но и данных и одноуровневых коллег. Это позволяет выравнивать общий уровень разработчиков в коллективе, позволяет им работать в одном стиле.
Код-ревью для начинающих: советы и ориентиры из практики