Кто должен делать обзоры кода?

12

В моей компании в основном архитектор делает обзоры кода. Он очень опытный и умный программист, поэтому он очень хорош в этом. Когда разработчики делают обзоры кода, они делают это не наполовину. Мы пытались дать разработчикам больше обзоров кода, но качество обзоров кода не было хорошим. Мы используем Scrum для в качестве методологии разработки.

Однако с существующей системой есть две проблемы:

Архитектор становится узким местом
Разработчики не несут ответственности за качество кода и архитектуры (что приводит к разного рода проблемам).

Как мы можем решить эти проблемы? Должны ли мы изменить, кто проверяет код?

code-reviews

— Евгений
источник

1

Возможные дубликаты Должны ли ваши лучшие программисты проверять чужой код в системе контроля версий?

— комнат

1

Я не вижу это как дубликат. Вопросы взаимосвязаны, но возможный дубликат сфокусирован на немного разных проблемах.

— Барт ван Инген Шенау

Не могли бы вы рассказать о том, что вы подразумеваете под «качеством проверки кода»? Вы имеете в виду качество кода, который появляется в конце обзора? Мне кажется, что у вас есть только один разработчик, который может создавать код приемлемого качества, и в этом случае я бы сказал, что у вас есть большие проблемы ...

— AakashM

15

Разработчики должны делать обзоры кода. Они должны делать обзоры кода, потому что они должны знать код, стандарты и практики фирменного стиля. Когда кто-то еще делает обзоры кода, вы говорите своим разработчикам, что они не несут ответственности за соответствие кода стандартам компании.

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

— jmoreno
источник

2

« Когда кто-то делает обзоры кода, вы говорите своим разработчикам, что они не обязаны следить за тем, чтобы код соответствовал стандартам компаний». Да и нет. Вы также говорите «Ваш код подлежит (надеюсь) критический пэр обзора, так что вам лучше сделать это правильно в первый раз.»

— JensG

@JensG: но это не коллега, который делает обзор в ситуации ОП.

— Jmoreno

3

Вот почему я сделал это смелым.

— JensG

8

В этой ситуации вам нужно знание этого опытного разработчика, чтобы помочь остальной части команды расти. Качество команды не определяется навыками лучшего разработчика; это определяется навыками худшего. Вы можете попробовать такие вещи, как:

Совместные обзоры. Это отлично сработало в моей последней команде. Мы поместили всю команду в комнату с проектором и начали просматривать некоторые предметы. Возможно, поначалу именно архитектор руководит обзором, но через несколько недель (мы зарезервировали один или два часа каждую пятницу), вся команда начинает говорить и понимать ключевые концепции, которые в настоящее время, кажется, знает только архитектор.
Парное программирование. Для меня это лучший инструмент для распространения знаний в команде.

— AlfredoCasado
источник

+1 для парного программирования. На самом деле, моим первым вопросом по этому вопросу было «все», но парное программирование лучше. Я думаю, что мы извлечем из этого максимум пользы, если сделаем его источником обучения помимо аспекта качества.

— JensG

3

В то время как я вижу смысл в том, чтобы системный / программный архитектор подписывал все изменения / коммиты, разработчики программного обеспечения должны иметь возможность проводить проверки без участия архитектора - за исключением арбитража.

Мои предпочтительные [*] процедуры проверки:

Группируйте изменения по требованию / проблеме.
Пригласите всех разработчиков, архитектора программного обеспечения и автора требования / проблемы на проверку. (Они не все обязаны делать обзор.)
Считать обзор законченным, когда:
- Два разработчика рассмотрели.
- Все комментарии отвечают. (Возможно, когда архитектор программного обеспечения примет решение.)
- Один рабочий день прошел без дальнейшего обсуждения (или все приглашенные стороны ознакомились).

Итак, мой краткий ответ на ваш вопрос: разработчики должны сделать обзоры изменения.

[*] К сожалению, не всегда так работают проекты, в которых я участвую.

— Джейкоб Спарре Андерсен
источник

сейчас всегда или не всегда?

— Мартейн

Как вы уже догадались: «не всегда». Спасибо, что заметили это. Я исправил ответ.

— Джейкоб Спарре Андерсен

3

Мне нравится практика периодических проверок кода команды, которые включают всю команду архитекторов, но потом много-много-много проверок кода между двумя или тремя членами команды.

Если это действительно сложный или деликатный код, то подключите архитектора или старших членов команды.

Честно говоря, звучит довольно смешно, когда архитектор делает обзоры кода. Он должен делать обзоры дизайна или случайные обзоры кода неформально, чтобы поделиться своим опытом. Команда разработчиков должна взять на себя ответственность за код. Если есть проблемы, то они со временем поправятся.

— обкрадывать
источник

2

Я согласен, если только один человек делает обзоры, остальные парни, вероятно, просто скажут: «Не знаю, похоже, это работает, но пусть этот умный парень выяснит, нормально это или нет». Я могу думать о следующем:

сделать ваш код общедоступным, чтобы каждый мог видеть, над чем все работают; выведите имена в начале каждого файла, содержащего код; возможно, распечатайте их и поставьте печать в ванной, или там, где вы чувствуете, это привлечет внимание
парное программирование; с другим мозгом рядом с вами, вы дважды подумаете, прежде чем назвать свою переменнуюi
возьмите своего уборщика и объясните ему, как работает это наследство (о, да, оно не работает). Объяснение вашего кода кому-то еще помогает. Может быть, он компилируется, может, он делает правильные вещи, но вы действительно не поняли, почему. Теперь ваш шанс
иметь набор руководящих принципов и заставить всех следовать им; независимо от руководящих принципов, это лучше, чем никаких руководящих принципов

— Mihai
источник