Должны ли мы попытаться просмотреть весь наш код?

В настоящее время мы модифицируем процесс разработки, и мне интересно, должны ли мы постараться сохранить 100% проверок наших коммитов.

Каков ваш опыт в отношении обзоров кода?

• Вы тратите на них «много» времени (скажем, 1/2 часа в день) или просто скользите в течение максимум 5/10 минут?
• У вас есть фиксированное количество времени, которое вы проводите в день / неделю / спринт / проект?
• Самое главное, считаете ли вы, что цель должна состоять в том, чтобы 100% кода было проверено коллегами или что в 100% нет необходимости?

У нас есть задача «Проверка кода» в каждой истории. Кто-то, в идеале не участвующий в разработке этой истории, рассмотрит все изменения кода, связанные с этой историей. Это работает хорошо.

Много времени? Не очень, зависит от того, сколько кода - мы ищем очевидные ошибки, опечатки, базовую проверку логики, невосприимчивые исключения и т. Д.

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

Кстати, важно, чтобы кто-то еще делал обзор кода ..

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

Сначала работайте над тем, чтобы сделать ваши отзывы более эффектными, затем определитесь с освещением.

Обзоры должны выполняться не только по коду, но и по дизайну.

Кроме того, обзоры не являются заменой для тестов и инструментов:

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

Попробуйте выделить заранее установленное количество времени в месяц (или на спринт) для обзоров. Выберите код, который вы хотите просмотреть в следующем выделенном слоте, используя эвристику, такую ​​как:

• Код, который может содержать неопознанную ошибку, о которой было сообщено
• В коде с этим недавно были обнаружены ошибки
• Код с проблемами производительности (узкие места)
• Код, написанный новыми разработчиками
• Устаревший код, который недавно был обновлен кем-то, кто ранее не был знаком с ним
• Код в новых областях
• Существующий код, о котором вы хотите, чтобы новые разработчики узнали
• Код, который решает сложные проблемы
• Код, который был определен как сложный с помощью инструментов анализа

И помните, вы просматриваете код (или дизайн или тесты), а не авторов.

Я рекомендую следующие материалы для чтения:

Выборочные обзоры без работы
Лучшие секреты рецензирования кода

По-разному.

Это зависит от того, что делает ваше программное обеспечение:

• Если он управляет электронным кардиостимулятором или космическим челноком, то определенно да.

• Если это одноразовый прототип, то, вероятно, нет.

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

Мой совет - сохранить ваши усилия по проверке кода для кода, где правильность критична и цена необнаруженных ошибок высока.

Сначала вам нужно ответить на этот вопрос: почему вы просматриваете код?

С этим ответом в руках вы можете выяснить, какой код необходимо пересмотреть.

Некоторые обзоры кода выполняют именно то, что тестирование делает или сделало бы. Если это и есть цель ваших обзоров, то если вы проводите небольшое тестирование, лучше приблизиться к 100%. Тем не менее, если позволить тестовым инструментам сделать это, то это уменьшит необходимость проверки всего кода.

Большинство хороших обзоров, похоже, сосредоточены на обмене знаниями и расширении возможностей разработчиков в обзоре (как того, кто написал код, так и тех, кто просматривает код). Учитывая это как основную причину проверок, проверка 100% кода, вероятно, излишняя.

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

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

Что касается времени, то все зависит от того, насколько высок компонент приоритета. Были времена, когда я проводил 10-15 минут, просматривая, и в других случаях несколько человек читали код по отдельности, а затем уходили в комнату, чтобы провести более формальный процесс проверки, который длится 30-45 минут (в зависимости от размера модуль).

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

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

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

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

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

Мы сделали 100% обзоров кода. Это намного дешевле, чем тестирование, особенно тестирование покрытия кода на 100%. Мы не тратим на них слишком много времени, обзор более часа в день становится менее продуктивным. (30 минут это не много).

В процессе установки нуля ведите записи. Что ты нашел? Что QA обнаружило позже? Что нашли ваши клиенты? Почему эти ошибки сбежали от вас?

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

Для каждой регистрации требуется проверка кода. Если нет равных, мы организуем проверку после регистрации. Рецензент отмечен в комментарии проверки исходного кода.

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

Проверка кода, IMO, необходима. Вы 99,999 ...% времени не всегда будете правы, поэтому вам нужно убедиться, что это правильно. У меня есть установленное время? Но я не тороплюсь, чтобы проверить мой код. Обычно у меня коллега делает то же самое.

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

Что касается того, сколько времени нужно потратить на рецензирование, хорошей практикой является оставить 5-10% от вашего общего предполагаемого времени разработки для проведения анализа кода и ответа на него.

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