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

Question

Я хотел бы знать, часто ли кто-то использует метрики для проверки своего кода / дизайна. В качестве примера, я думаю, я буду использовать:

• количество строк на метод (<20) </li>
• количество переменных на метод (<7) </li>
• количество параметров на метод (<8) </li>
• количество методов в классе (<20) </li>
• количество полей в классе (<20) </li>
• Глубина дерева наследования (<6). </li>
• Отсутствие сплоченности в методах

Большинство этих метрик очень просты.

Как вы относитесь к такого рода мемурам? Используете ли вы инструмент для проверки их (например, NDepend)?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

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

Обновление Мы используем инструмент сейчас, чтобы обнаружить возможные проблемы в источнике. Мы добавили несколько метрик (не все чисто OO):

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

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