Оценка метрик кода

Было много дискуссий о метриках кода (например: чем увлекаются метрики кода?). Я (как разработчик программного обеспечения) действительно интересуюсь этими метриками, потому что я думаю, что они могут помочь написать лучший код. По крайней мере, они полезны, когда дело доходит до поиска областей кода, которые требуют некоторого рефакторинга.

Однако я хотел бы знать следующее. Существуют ли некоторые оценки этих метрик исходного кода, которые доказывают, что они действительно коррелируют с частотой ошибок или ремонтопригодностью метода. Например: действительно ли методы с очень высокой цикломатической сложностью вносят больше ошибок, чем методы с низкой сложностью? Или методам с высоким уровнем сложности (Холстеду) действительно нужно гораздо больше средств для их поддержания, чем методам с низким уровнем?

Может быть, кто-то знает о каких-то надежных исследованиях в этой области.

Большое спасибо!

Источник

6 ответов

Решение

Хороший вопрос, нет прямого ответа.

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

Я нашел следующее: http://www.pitt.edu/~ckemerer/CK%20research%20papers/CyclomaticComplexityDensity_GillKemerer91.pdf. Хотя это показывает связь между цикломатической сложностью и производительностью. Тем не менее, в нем есть несколько ссылок на другие статьи, и стоит попробовать их в Google.

Источник

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

Источник

Наконец, я нашел несколько статей о корреляции между метриками программного обеспечения и частотой ошибок, но ни одна из них не была тем, что я искал. Большинство работ устарели (конец 80-х или начало 90-х).

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

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

Источник

Мы провели эмпирическое исследование возможностей предсказания ошибок в известных объектно-ориентированных метриках Чидамбера и Кемерера. Оказалось, что эти метрики вместе могут прогнозировать ошибки с точностью выше 80%, когда мы применяем правильные модели машинного обучения. Если вы заинтересованы, вы можете подготовить полное исследование в следующей статье:

"Эмпирическая проверка объектно-ориентированных метрик на программном обеспечении с открытым исходным кодом для прогнозирования неисправностей. В IEEE транзакциях по программной инженерии, том 31, № 10, октябрь 2005 г., стр. 897-910".

Источник

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

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

  • Инструмент(ы) Операционная система
  • Тип кода (встроенный, серверный, графический интерфейс, веб)
  • Уровень опыта разработчика
  • Уровень навыков разработчика
  • Фон разработчика
  • Среда управления
  • Акцент на качество
  • Стандарты кодирования
  • Программные процессы
  • Тестовая среда/практики
  • Стабильность требований
  • Проблемная область (бухгалтерия/телеком/военные/и т.д.)
  • Размер/возраст компании
  • Архитектура системы
  • Язык(и)

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

https://shape-of-code.com

Эта ссылка хороша тем, что она разбирает одну из наиболее заметных метрик, индекс ремонтопригодности, который можно найти в Visual Studio:

https://avandeursen.com/2014/08/29/think-twice-before-using-the-maintainability-index/

См. эту статью для хорошего обзора довольно большого количества метрик, показывающего, что они плохо коррелируют с понятностью программы (которая сама по себе должна коррелировать с ремонтопригодностью): «Автоматическая оценка понятности кода: как далеко мы?», Скалабрино и др. др.

Источник
Другие вопросы по тегам