Индекс ремонтопригодности

Я натолкнулся на рекомендуемые значения индекса ремонтопригодности (МИ) следующим образом:

  • 85 и более: хорошая ремонтопригодность
  • 65-85: умеренная ремонтопригодность
  • 65 и ниже: трудно поддерживать с действительно плохими частями кода (большой, некомментированный, неструктурированный), значение MI может быть даже отрицательным

Эти значения зависят от технологии? Например, значение 70 хорошо для мейнфреймов, но трудно поддерживать для Java?

Можно ли использовать один и тот же критерий независимо от технологий?

5 ответов

Это объяснение значения значения показателя ремонтопригодности.

Коротко это

MI = 171 - 5.2*ln(Halstead Volume) - 0.23*(Cyclomatic Complexity) - 16.2*ln(Lines of Code)

масштабируется от 0 до 100.

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

Пороговые значения 65 и 85 взяты из оригинальной статьи, в которой вводится Индекс ремонтопригодности в 1992/1994 гг.

Visual Studio немного скорректировала метрику (умножение на 100/171), чтобы она соответствовала шкале 1-100. Visual Studio использует 10 и 20 в качестве порогов.

В общем, я бы не воспринимал этот показатель и его пороги слишком серьезно: см. Также мой пост в блоге " Дважды подумайте, прежде чем использовать индекс ремонтопригодности".

Индекс ремонтопригодности является эмпирической формулой. Это была построена модель, основанная на наблюдении и адаптации. Если вы ищете более подробную информацию, вы обнаружите, что уравнение должно быть разогнано для конкретного языка. Версия SEI откалибрована для Pascal и C и использует несколько программ, в среднем 50KLOC, поддерживаемых Hewlett-Packard.

Калибровка версии Visual Studio такая же, как и в версии SEI, но была проверена для ограничения домена от 0 до 100.

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

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

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

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

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

Может показаться разумным провести простое сравнение "числа строк на функцию", но что происходит, когда вы пытаетесь сравнить код C, который полон указателей, или код C++, полный шаблонов, или C# с запросами LINQ, или Java с дженерики?
Все эти вещи влияют на удобство обслуживания, но не могут быть измерены каким-либо значимым межъязыковым способом, так как же вы когда-нибудь сможете сравнить числа между двумя языками?

Другие вопросы по тегам