Как определить эффективность процесса проверки кода?

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

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

Кто-нибудь сталкивался с этой проблемой раньше или есть мысли о том, что хорошо работает при измерении обзоров кода?

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

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

Различные метрики встреч также будут актуальны. К ним относятся время подготовки, время встречи, строки считывания кода, дефекты, обнаруженные в обзоре, и так далее. Из этих данных можно сделать некоторые наблюдения. Например, если ваши рецензенты тратят много времени на чтение кода при подготовке к обзору, но обнаруживают очень мало проблем. В сочетании с данными DRE вы можете сделать вывод, что если дефекты проверяются в ходе интеграционных испытаний или в полевых условиях, то ваша группа должна сосредоточиться на своих методах проверки, чтобы иметь возможность находить проблемы. Другим интересным примечанием могут быть строки кода (или некоторые другие измерения размера), прочитанные на собрании, по сравнению со временем собрания. Исследования показали, что скорость типичного просмотра кода составляет 150 строк кода в час.

При использовании любого из этих показателей важно понять их влияние на процесс. Анализ первопричин с использованием таких методов, как « почему-потому» , диаграммы Five Whys или Исикавы могут быть использованы для определения причин, по которым проверки кода (или любые другие методы улучшения качества) (не) эффективны.

Вас также может заинтересовать эта статья об инспекциях The Ganssle Group и статья Capers Jones в Crosstalk о возможностях дефектов и DRE .

Хотя в значительной степени верно, что проверка кода выявляет проблемы, которые являются довольно скрытыми, что тестирование может или не может поймать. Тем не менее, по моему мнению, у вас может быть действительно стабильный (практически без ошибок) код, но все же написанный таким образом, что он крайне не читается или не совсем поддерживается. Таким образом, может случиться так, что проверка кода НЕ МОЖЕТ найти ошибок, если в коде нет реальных проблем.

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

Как вы хотели измерить эффективность - вот что я хотел бы предложить:

1. Метрика, относящаяся к количеству переделок - Количество времени, в которое переделка применяется в одном и том же модуле / объекте / рабочем элементе, является показателем того, насколько плох этот код с точки зрения удобства сопровождения. Когда применяется эффективный пересмотр кода, как часто мы можем сократить количество запросов на повторную обработку в одном модуле?

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

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

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

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