Какая метрика (метрики) могла помочь указать, что у меня есть процессуальный кодекс вместо объектно-ориентированного кода? Я хотел бы иметь ряд простых метрик, которые указывают с высокой вероятностью, что проанализированный код содержит процедурные сценарии транзакции и анемичную модель предметной области вместо следующих звуковых объектно-ориентированных принципов разработки.
Было бы довольно любым набором полезных метрик и инструментов для измерения.
Спасибо, Thomas!
Метрики, ориентированные на сплоченность и сцепление должны дать хорошее представление о том, что ваши классы реальны, а не коллекции функций. Здесь есть очень удобочитаемая статья , которую я цитирую ниже, чтобы показать, почему я считаю сплоченность хорошей метрикой:
«Сплоченность относится к родству» компонентов модуля. Компонент с высокой степенью сплоченности - это компонент, выполняющий одну базовую функцию. Разделить связный компонент должно быть сложно. Сплоченность можно классифицировать с помощью порядковой шкалы, которая варьируется от наименее желательной категории (случайная сплоченность) до наиболее желательной (функциональная сплоченность) ».
Классическим измерением сплоченности является « Недостаток сплоченности в методах »Чидамбера и Кемерера. "(LCOM) .Вы также можете посмотреть Ответ для класса (RFC) , который измеряет связь между методами в классе.
Вы можете рассмотреть такие проектные метрики, как NOC и DIT , но мой собственный опыт показывает, что они слишком грубые и легко запутываются классами в сторонней структуре.
Вы не сказали, какой язык вы используете, но есть некоторые инструменты, созданные на основе Eclipse, поэтому быстрый поиск в Интернете объектно-ориентированных показателей на основе Eclipse должен дать что-то полезное
Некоторые просто не в себе
Они не убедитесь, что ваш код более объектно-ориентированный или более процедурный, но, возможно, это поможет.