Как вы продвигаете культуру анализа однорангового кода с вашей командой?

Ответ 1

Мы приняли несколько вещей, которые помогают обзорам кода быть более полезными.

• Мы дали понять, что отзывы не личной и не виноватой ситуации. Необходимо поощрять разговор, даже если это не то, что кто-то хочет слышать.
• Довольно неофициально. Слишком много процесс может быть его смертью.
• Разрешить рецензентам делать это на своих время. Передайте информацию и дайте дату закончить.
• У нас есть FAQ для общего типа обзора вопросы, которые помогают всем говоря на одном языке.
• Определить реальное время ресурса для обзоры. Не следует рассматривать как после этого, но больше как шаг.
• Храните обзоры небольшими/сфокусированными и делайте часто. Не делайте это особым мероприятие. Это должно происходить ежедневно/еженедельно.
• Кроме того, у вас слишком много рецензентов. Для этого требуется намного больше времени. Очевидно, включают рецензентов, которые знакомы с дизайном кода (возможно, они участвовали в ранних высокий уровень и/или подробный дизайн отзывы?).

Еще много, но хороший список для начала!

Связанная ветка: Каков наилучший способ поощрения общения в команде?

Ответ 2

Следующие результаты хорошо работали для моих команд.

• Был просмотрен каждый фрагмент кода. перед входом в "сборку".
• Отзывы были наставничество (упоминается в других ответах), а не состязательности. Отклонения от этого рассматривались как образовательные возможности.
• У нас была система обзора, связанная с контролем источника, чтобы отслеживать несоблюдение (красиво).
• Система обзора позволила нам сделать статистику как для рецензентов, так и для рецензентов.
• Один рецензент за просмотр, как часто, как "старший".
• Четкое кодирование стандартов и ожидания.
• Обзор diffs не весь код - избегает выбора существующего кода.
• Предполагалось, что автор кода сначала просмотрит свой материал, и это было жестко соблюдено. Поэтому, хотя мы поощряли процесс наставничества по большей части, если кодер просто бросил мусор над стеной, который не строился, мы отбросили его с тиканием.
• Мы рассмотрели все: построили код, проверили стандарты кодирования, выборочно проверили единичные тесты, чтобы убедиться, что они были запущены и прошли также требования.
• Комментарии были записаны в базе данных, но мы настаивали на том, чтобы говорить через обзор, а не просто оставлять комментарии, которые нужно подобрать, и часто пропускать интерпретацию - позже. Используйте телефон + чат для удаленных разработчиков.

Звучит дорого? Фактически, он многократно возвращался при более низких затратах на обслуживание.

Невозможно реализовать в старой команде? Нет. Мы внедрили это из-за отсутствия обзора кода, установили ожидания и просто сохранили его, пока это не стало основой нашего процесса. Это создало команду, которая была просто превосходной, которая имела фантастически низкий уровень дефектов и хорошо впитывала новых людей (обычно). Когда эта команда распалась, это был самый печальный день в моей карьере.

Ответ 3

Что вы нашли успешным в ваших командах? Во-первых:

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

Сейчас:

Единственное, что действительно выгодно, это то, что вы должны показать им, почему это важно. Как только они получат это, они не захотят жить без него. Ключом к тому, чтобы заставить их принять его, - позволить им настроить его на своих условиях. Скажите им, что вы думаете, что это была бы хорошая идея и получить их предложения о том, как ее реализовать. Если вы попытаетесь рассказать им, как это будет, все шансы - это усугубить их, и они будут сопротивляться его принятию. Им нужно пройти этап обучения, пытаясь понять, как заставить его работать. Когда они "владеют" процессом (думают, что это их собственные), они начнут применять его, потому что это было их решение.

Ответ 4

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

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

Ответ 5

Когда вы хотите что-то сделать с этим процессом, вы можете изменить рабочий процесс своих рабочих элементов, включив в него состояние "Проверка кода". (это может быть необязательное или требуемое состояние)

Затем у вас есть хотя бы список всех элементов для проверки кода.

Вы также можете посмотреть проект TeamReview на codeplex: http://teamreview.codeplex.com/

Ответ 6

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

Я думаю, что эта практика должна быть нормой везде.