Что привлекают ваши обзоры кода и какие шаблоны успешны?

Ответ 1

Я не думаю, что должно быть формальное и неофициальное, так как существуют разные типы времени, разрешенные для просмотра кода. Если есть ошибка, которая будет исправлена ​​как ASAP, а изменение кода - всего несколько строк кода, это все равно может быть рассмотрено, но, скорее всего, не так, как если бы вы создавали новую систему ERP или CRM. Кроме того, в некоторых случаях часы могут быть отложены для просмотра кода, а в других - менее 5 минут.

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

Что касается последнего вопроса, я думаю, что ответ иногда. Если у вас есть код, в котором вы хотите получить другие мнения о том, как оптимизировать код, то отсутствие участия автора может быть полезным при получении идей, а затем, если автор либо внесет изменения, либо оправдает, почему это изменение не улучшает кода, например если кто-то хочет ввести алгоритм сортировки пузырьков, это может быть отклонено из-за других более эффективных алгоритмов сортировки, таких как quicksort, mergesort и heapsort.

Отредактировано для добавления нескольких шаблонов, которые я нашел полезными: Для проверки кода исправления ошибок шаблон, который мне больше всего нравится, следующий: 1) Покажите ошибку в тестовой/промежуточной среде, чтобы я мог видеть, что пошло не так. 2) Покажите мне, где был изменен код, и краткое объяснение, почему оно было изменено таким образом. 3) Покажите мне, что код исправлен на вашей локальной машине.

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

Ответ 2

Лучшие обзоры кода, которые я когда-либо делал, включали инструмент "Коллаборатор кодов" от Smartbear. Автор загружает код на сервер. Рецензенты и наблюдатели могут видеть различия между новым кодом и старым кодом и комментировать новый код. Вот рекомендации:

• Автор комментирует написанный код, чтобы дать понять рецензента о том, с чего начать.
• Рецензент комментирует и добавляет дефекты, которые необходимо будет устранить до того, как будет принят обзор. Только важные вещи должны быть отмечены как дефекты. Не опечатки или вещи, которые вы знаете, разработчик будет исправлять до совершения.
• Привлечь новых разработчиков в качестве наблюдателей. Это хорошая подготовка, чтобы познакомить их с проектом.
• Привлекайте "экспертов" к фрагменту кода, как наблюдателя или рецензента.

Анти-паттерны:

• Используйте инструмент проверки кода в качестве инструмента для проверки дизайна. Это не подходит для этого. Только просмотрите код, для которого был согласован проект.
• Вовлекайте слишком много рецензентов и наблюдателей.
• Пусть обзор задерживается в системе более чем на пару дней.

Ответ 3

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

Ответ 4

• Расписание или проверки регулярно и часто. Обзор/Проверка целых модулей, когда новый, и дельты + окружающие код для обслуживания. Создание отставания материала, подлежащего рассмотрению, заставляет весь процесс запугивать.

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

• Не просто просматривать/проверять код; смотреть   при испытаниях (особенно для TDD) и   результаты тестов тоже. Мы обнаружили   некоторые интересные ошибки и тесты   упущения, открыв, что   мы думали, что мы тестировали, не было   действительно то, что тестировалось, или   что мы случайно использовали тест   данные из того же класса эквивалентности   когда мы думали, что используем   различные классы данных.

Ответ 5

Моя компания, "Смарт-медведь", делает коллаборатор кода (как упоминается David Segonds). Мы также предоставляем бесплатную книгу под названием Лучшие секреты обзора одноранговых кодов. Он получил некоторые хорошие передовые методы, которые мы узнали от работы с нашими клиентами и изучения другой литературы.

Вот несколько моментов:

• Храните обзор кода небольшим. Слишком много кода сразу становится ошеломляющим, поэтому, если у ваших обзоров слишком много кода, просмотрите их чаще в меньших фрагментах.
• Вовлекайте всех, но не всех сразу. Обзор кодов - это шанс для всех учиться, рецензентов и авторов.
• Помните, это о коде, а не об авторе.

Ответ 6

Начните с взгляда на концепцию проверки Fagan.

Этот метод действительно помогает качеству рассмотренного кода и самому обзору!

И всегда помните, чтобы критиковать код, а не кодер.

Ответ 7

Используя Eclipse Jupiter plugin и следуя процессу, который он автоматизирует, отлично сработал для нас. Он не слишком инвазивный или бюрократический, но он по-прежнему помогает найти ошибки и проблемы с дизайном.