Всякий раз, когда я слышу о попытках связать некоторый тип метрики на основе кода с дефектами программного обеспечения, первое, о чем я думаю, это цикломатическая сложность МакКейба . Различные исследования показали, что существует корреляция между высокой цикломатической сложностью и количеством дефектов. Однако другие исследования, в которых рассматривались модули с одинаковым размером (с точки зрения строк кода), обнаружили, что корреляции может и не быть.
Для меня и количество строк в модуле, и цикломатическая сложность могут служить хорошими показателями возможных дефектов или, возможно, большей вероятности того, что дефекты будут введены, если в модуль будут внесены изменения. Модуль (особенно на уровне класса или метода) с высокой цикломатической сложностью труднее понять, поскольку в коде существует большое количество независимых путей. Модуль (опять же, особенно на уровне класса или метода) с большим количеством строк также трудно понять, так как увеличение количества строк означает, что происходит больше вещей. Существует много инструментов статического анализа, которые поддерживают вычисление строк исходного кода в соответствии с заданными правилами и цикломатической сложностью. Кажется, что захват их приведет к получению низкого результата.
Эти меры сложности Halstead также могут быть интересны. К сожалению, их обоснованность, по-видимому, несколько обсуждается, поэтому я не буду полагаться на них. Одной из мер Холстеда является оценка дефектов, основанная на усилии или объеме (взаимосвязь между длиной программы в терминах общих операторов и операндов и лексики программы в терминах различных операторов и операторов).
Существует также группа показателей, известных как CK Metrics. Первое определение этого набора метрик, по-видимому, содержится в статье под названием «Набор метрик для объектно-ориентированного проектирования» Чидамбера и Кемерера. Они определяют взвешенные методы для каждого класса, глубину дерева наследования, количество дочерних элементов, связь между классами объектов, реакцию на класс и отсутствие единства в методах. Их статья предоставляет вычислительные методы, а также описание того, как анализировать каждый из них.
С точки зрения академической литературы, которая анализирует эти метрики, вас может заинтересовать эмпирический анализ метрик CK для объектно-ориентированной сложности проектирования: последствия для дефектов программного обеспечения, автором которых являются Раманат Субраманьям и М.С. Кришна. Они проанализировали три из шести метрик CK (взвешенные методы на класс, связь между классифицируемым объектом и глубиной дерева наследования). Просматривая статью, выясняется, что они обнаружили, что это потенциально допустимые показатели, но их следует осторожно интерпретировать как «улучшение», которое может привести к другим изменениям, которые также приводят к большей вероятности появления дефектов.
Эмпирический анализ объектно-ориентированных проектных метрик для прогнозирования сбоев высокой и низкой серьезности, автором которых являются Юминг Чжоу и Харетон Леунг, также исследует метрики CK. Их подход состоял в том, чтобы определить, могут ли они прогнозировать дефекты на основе этих метрик. Они обнаружили, что многие метрики CK, за исключением дерева глубины наследования и числа детей), имели некоторый уровень статистической значимости в прогнозировании областей, в которых могут быть обнаружены дефекты.
Если у вас есть членство в IEEE, я бы порекомендовал поискать в « Транзакциях IEEE по программной инженерии» больше научных публикаций, а в « IEEE Software» - несколько более реальных и прикладных отчетов. ACM может также иметь соответствующие публикации в своей цифровой библиотеке .