Метрики и объектно-ориентированное программирование

Установление числовых ограничений на эти значения (как вы, кажется, подразумеваете с числами), на мой взгляд, не очень хорошая идея. Количество строк в методе может быть очень большим, если есть значительный оператор switch, и тем не менее метод остается простым и правильным. Количество полей в классе может быть очень большим, если поля простые. А пять уровней наследования иногда может быть слишком много.

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

Показатель, который я не видел в вашем списке, - это цикломатическая сложность Маккейба. Он измеряет сложность данной функции и коррелирует с ошибками. Например. высокие оценки сложности функции указывают на: 1) вероятно, что функция содержит ошибки и 2) вероятно, что ее трудно исправить должным образом (например, исправления представят их собственные ошибки).

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

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

Это не значит, что метрики бесполезны. Показатели наиболее полезны при изменении для поиска областей, которые могут изменяться неожиданным образом. Например, если вы внезапно перейдете с 3 уровней наследования на 15 или с 4 парм на метод до 12, углубитесь и выясните, почему.

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

Так что не полагайтесь на метрики как на абсолютные индикаторы чего-либо; ничто не заменит чтение / просмотр кода.

Лично я считаю, что очень сложно придерживаться таких требований (т.е. иногда вам действительно нужен метод с более чем 20 строками), но в духе вашего вопроса я упомяну некоторые рекомендации, используемые в эссе под названием < em> Object Calisthenics (часть антологии Thoughtworks, если вам интересно).

• Уровни отступа на метод (‹2)
• Количество точек в строке (‹2)
• Количество линий в классе (‹50)
• Количество занятий в пакете (‹10)
• Количество вариантов экземпляра на класс (‹3)

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

Точные цифры не подходят для каждого решения. Некоторые решения сложнее других. Я бы начал с них как с ваших рекомендаций и посмотрел, чем закончится ваш проект (ы).

Но, что касается конкретно этих цифр, эти цифры кажутся довольно высокими. Я обычно нахожу в своем конкретном стиле кодирования то, что у меня обычно есть:

• не более 3-х параметров на метод
• подпись около 5-10 строк на метод
• не более 3-х уровней наследования

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

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

OO Metrics - это что-то вроде любимого проекта для меня (это было предметом моей магистерской диссертации). Так что да, я использую их, и я использую свой собственный инструмент.

В течение многих лет книга Марка Лоренца «Объектно-ориентированные программные метрики» была лучшим источником объектно-ориентированных метрик. Но в последнее время я видел больше ресурсов.

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

Обновление. Сейчас мы используем этот инструмент для обнаружения возможных проблем в источнике. Мы добавили несколько метрик (не все чисто объектно-ориентированные):

• использование утверждения
• использование магических констант
• использование комментариев относительно сложности методов
• уровень вложенности операторов
• зависимость класса
• количество публичных полей в классе
• относительное количество переопределенных методов
• использование операторов goto

Есть еще кое-что. Мы оставляем те, которые дают хорошее представление о болевых точках в коде. Так что мы получим прямую обратную связь, если они будут исправлены.