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

Question

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

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

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

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

Answer 1

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

Вскоре это

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

от 0 до 100.

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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