Я хочу лучше понять шаблоны, которые работают, и шаблоны, которые не работают для успешных обзоров кода.
Должна ли быть разница в рассмотрении формального кода и обзоре неформального кода?
Какой уровень документации для обзора кода делают люди?
Может ли обзор кода быть таким же полезным без участия автора кода?
Я не думаю, что должно быть формальное и неофициальное, так как существуют разные типы времени, разрешенные для просмотра кода. Если есть ошибка, которая будет исправлена как ASAP, а изменение кода - всего несколько строк кода, это все равно может быть рассмотрено, но, скорее всего, не так, как если бы вы создавали новую систему ERP или CRM. Кроме того, в некоторых случаях часы могут быть отложены для просмотра кода, а в других - менее 5 минут.
Документация может быть в нескольких формах. Это может быть просто электронная почта, в которой говорится, что Джо рассмотрел работу Боба и что это одобрено для перехода на следующий этап выпуска. В качестве альтернативы, может быть несколько страниц заметок о том, что нужно изменить, прежде чем продвигать код, чтобы использовать некоторые шаблоны проектирования, а код очищается от его начальной быстрой и грязной формы.
Что касается последнего вопроса, я думаю, что ответ иногда. Если у вас есть код, в котором вы хотите получить другие мнения о том, как оптимизировать код, то отсутствие участия автора может быть полезным при получении идей, а затем, если автор либо внесет изменения, либо оправдает, почему это изменение не улучшает кода, например если кто-то хочет ввести алгоритм сортировки пузырьков, это может быть отклонено из-за других более эффективных алгоритмов сортировки, таких как quicksort, mergesort и heapsort.
Отредактировано для добавления нескольких шаблонов, которые я нашел полезными: Для проверки кода исправления ошибок шаблон, который мне больше всего нравится, следующий: 1) Покажите ошибку в тестовой/промежуточной среде, чтобы я мог видеть, что пошло не так. 2) Покажите мне, где был изменен код, и краткое объяснение, почему оно было изменено таким образом. 3) Покажите мне, что код исправлен на вашей локальной машине.
В отличие от этого, если один реализует API с дюжиной методов, то может быть лучше иметь некоторую документацию, которая суммирует то, что использовалось в реализации, и почему были сделаны некоторые выборы, например. какая реализация списка использовалась как массив, хеш-таблица, связанный список, общий список, стек, очередь и т.д.
Лучшие обзоры кода, которые я когда-либо делал, включали инструмент "Коллаборатор кодов" от Smartbear. Автор загружает код на сервер. Рецензенты и наблюдатели могут видеть различия между новым кодом и старым кодом и комментировать новый код. Вот рекомендации:
Анти-паттерны:
Образец, который я считаю критическим для хороших обзоров кода, имеет программистов со временем и мотивацией, чтобы действительно читать и понимать код в качестве рецензентов. Рецензенты, которые только дают код беглым взглядом и указывают на несколько изменений стиля кода, действительно не способствуют процессу.
Расписание или проверки регулярно и часто. Обзор/Проверка целых модулей, когда новый, и дельты + окружающие код для обслуживания. Создание отставания материала, подлежащего рассмотрению, заставляет весь процесс запугивать.
Все коды проверяются, начиная с самый младший из самых старших, и любой может комментировать без страха обвинения.
Не просто просматривать/проверять код; смотреть при испытаниях (особенно для TDD) и результаты тестов тоже. Мы обнаружили некоторые интересные ошибки и тесты упущения, открыв, что мы думали, что мы тестировали, не было действительно то, что тестировалось, или что мы случайно использовали тест данные из того же класса эквивалентности когда мы думали, что используем различные классы данных.
Моя компания, "Смарт-медведь", делает коллаборатор кода (как упоминается David Segonds). Мы также предоставляем бесплатную книгу под названием Лучшие секреты обзора одноранговых кодов. Он получил некоторые хорошие передовые методы, которые мы узнали от работы с нашими клиентами и изучения другой литературы.
Вот несколько моментов:
Начните с взгляда на концепцию проверки Fagan.
Этот метод действительно помогает качеству рассмотренного кода и самому обзору!
И всегда помните, чтобы критиковать код, а не кодер.
Используя Eclipse Jupiter plugin и следуя процессу, который он автоматизирует, отлично сработал для нас. Он не слишком инвазивный или бюрократический, но он по-прежнему помогает найти ошибки и проблемы с дизайном.