В моей компании в основном архитектор делает обзоры кода. Он очень опытный и умный программист, поэтому он очень хорош в этом. Когда разработчики делают обзоры кода, они делают это не наполовину. Мы пытались дать разработчикам больше обзоров кода, но качество обзоров кода не было хорошим. Мы используем Scrum для в качестве методологии разработки.
Однако с существующей системой есть две проблемы:
Архитектор становится узким местом
Разработчики не несут ответственности за качество кода и архитектуры (что приводит к разного рода проблемам).
Как мы можем решить эти проблемы? Должны ли мы изменить, кто проверяет код?
code-reviews
Евгений
источник
источник
Ответы:
Разработчики должны делать обзоры кода. Они должны делать обзоры кода, потому что они должны знать код, стандарты и практики фирменного стиля. Когда кто-то еще делает обзоры кода, вы говорите своим разработчикам, что они не несут ответственности за соответствие кода стандартам компании.
Если вы думаете, что им нужно учиться делать обзоры кода, купите это для них. Учитывая вашу текущую ситуацию, вы можете попросить разработчика выполнить проверку кода, а затем прокомментировать его вашим архитектором - пусть разработчик передаст обзор архитектору для утверждения, а затем отправит его отправителю.
источник
В этой ситуации вам нужно знание этого опытного разработчика, чтобы помочь остальной части команды расти. Качество команды не определяется навыками лучшего разработчика; это определяется навыками худшего. Вы можете попробовать такие вещи, как:
Совместные обзоры. Это отлично сработало в моей последней команде. Мы поместили всю команду в комнату с проектором и начали просматривать некоторые предметы. Возможно, поначалу именно архитектор руководит обзором, но через несколько недель (мы зарезервировали один или два часа каждую пятницу), вся команда начинает говорить и понимать ключевые концепции, которые в настоящее время, кажется, знает только архитектор.
Парное программирование. Для меня это лучший инструмент для распространения знаний в команде.
источник
В то время как я вижу смысл в том, чтобы системный / программный архитектор подписывал все изменения / коммиты, разработчики программного обеспечения должны иметь возможность проводить проверки без участия архитектора - за исключением арбитража.
Мои предпочтительные [*] процедуры проверки:
Итак, мой краткий ответ на ваш вопрос: разработчики должны сделать обзоры изменения.
[*] К сожалению, не всегда так работают проекты, в которых я участвую.
источник
Мне нравится практика периодических проверок кода команды, которые включают всю команду архитекторов, но потом много-много-много проверок кода между двумя или тремя членами команды.
Если это действительно сложный или деликатный код, то подключите архитектора или старших членов команды.
Честно говоря, звучит довольно смешно, когда архитектор делает обзоры кода. Он должен делать обзоры дизайна или случайные обзоры кода неформально, чтобы поделиться своим опытом. Команда разработчиков должна взять на себя ответственность за код. Если есть проблемы, то они со временем поправятся.
источник
Я согласен, если только один человек делает обзоры, остальные парни, вероятно, просто скажут: «Не знаю, похоже, это работает, но пусть этот умный парень выяснит, нормально это или нет». Я могу думать о следующем:
i
источник