По моему опыту, лучший способ - дать команде дыр сделать обзор кода. Мы используем список рассылки коммитов в каждом проекте, где вы можете следить за каждым изменением кода в системе контроля версий. Большинство наших разработчиков подписались на свой список рассылки для своего проекта, потому что они заинтересованы в изменениях кода.
Когда кто-то замечает плохой путь в новом исходном коде, он либо объясняет коммиттеру, как он может сделать это лучше, если коммиттер является стажером, либо он начинает обсуждение этого вопроса, если он был более опытным коммиттером.
Конечно, этот метод не гарантирует пересмотра всего нового кода, особенно в стрессовые времена, когда никто из членов команды не имеет возможности следить за каждым изменением кода. Кроме того, не каждый разработчик несет ответственность за обеспечение того, чтобы каждый разработчик делал свою работу хорошо, в одиночку вы не можете гарантировать, что она будет рассмотрена. Но, по крайней мере, в наших командах всегда есть технический менеджер, который отвечает за техническое качество.
Я настоящий поклонник обзоров кода, если они соответствуют следующим оценкам:
- каждый разработчик имеет возможность пересмотреть весь код и аргументировать свое мнение
- никто не имеет права злоупотреблять чужим кодом
- не только плохой код активирует обсуждение, но и хороший код тоже
- обсуждение заканчивается счастьем для всех вовлеченных людей
- обзор происходит почти в режиме реального времени, по крайней мере, до завершения функции
Я узнал, что если вы - тот, кто просматривает каждую строку кода и считает, что вам необходимо контролировать такие вещи, как качество кода с точки зрения форматирования кода или эффективности кода, то вы сами очень неэффективны, потому что вы делаете вещи, для которых машины могут сделать вы. Ваша цель должна заключаться в использовании системы непрерывной интеграции, которая контролирует сборку и качество кода каждого вклада в код. Если эта система генерирует отчеты и отправляет их авторам, все идеально.
Я должен признать, что если вам нужно пересмотреть код, потому что вы должны контролировать или оценивать качество программиста, то мои предложения не имеют смысла. В этом случае я бы также не рассматривал исходный код построчно. Я хотел бы рассмотреть такие вещи, как:
- есть ли проблемы, связанные с безопасностью
- предназначены API, используемые
- применил ли код указанную архитектуру
- он написал полезные тесты (но только если он был проинструктирован, я должен был учиться)
- Документация
- строить-процесс
- ... и еще немного, вероятно
Если вы опытный разработчик, вы обязательно найдете такие вещи, как циклы, которые вы могли бы сделать с лучшей производительностью. Конечно, полезно объяснить другим такие знания, но это не должно быть частью обзорной сессии. Если есть существенные проблемы с производительностью, то не потому, что он (или она) использовал менее эффективный вариант типа списка.
Поскольку первоначальный вопрос заключался в том, почему некоторые люди, по-видимому, делают более качественный обзор, чем другие, я бы ответил, что эти люди, возможно, делают предварительный просмотр до того, как начнется реальный обзор, что означает, что они, вероятно, подготовлены сами, чтобы точно знать, что они хотят просмотреть ,