Кодовые показатели

Мне просто интересно, какие именно показатели метрики люди используют и мнения/опыт по наиболее эффективному использованию метрик кода. Весь наш код, независимо от языка, использует следующее:

  • Cyclomatic Code Complexity
  • Линии кода
  • Связывание (имеет разные значения для языков OO, чем в процедурных и шаблонных языках)

Мера сложности была наиболее эффективной для нас в выявлении потенциальных кошмаров обслуживания. В меньшей степени LOC также был полезен как относительная мера (если мы увидим, что у класса есть еще 20 строк, чем средний класс). Связь была менее полезной, обычно наиболее полезной при рассмотрении того, как много мы можем перерыв с изменением.

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

Ответы

Ответ 1

Вы получаете то, что вы измеряете.

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


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

  • Скорость сбоя ежедневной сборки (с анализом основных причин сбоев), target < 20%
  • Тестирование пробега/пропускной способности (как автоматизированных, так и ручных тестов), целевые показатели различаются на один этап проекта; при целевом значении конечной скорости 100%, скорости прохождения 95%
  • Функция тестирования и охват решений для нового кода (не-пользовательский интерфейс, без права доступа, не портированный), 100% для функций API, 80% для других функций, 50% для принятия решений
  • Открыть счетчик ошибок по приоритету, цель увидеть плоскую или уменьшающуюся кривую (достаточная емкость для исправления ошибок в команде), отсутствие открытых высокоприоритетных ошибок
  • Инспекция: размер компонента, контроль, проблемы, обнаруженные по степени серьезности; цель, чтобы получить своего рода дефект/усилие/loc эвристическая мера, чтобы убедиться, что компоненты тщательно проверены.
  • Статические инструменты анализа, такие как lint и некоторые инструменты для работы с конкретными доменами, проблемы с высоким приоритетом исправлены или поняты
  • Оценка скорости команды против фактического спринта, цель уменьшения ошибки оценки до менее 20%.

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

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

Ответ 2

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

Мой предыдущий работодатель сохранил показатели сложности кода и строки кода. У них также были ограничения на длину файлов классов. Классы, которые стали слишком большими, должны были пройти проверку кода, чтобы их можно было разбить на более мелкие классы. Время от времени это была боль в прикладе, но она сохраняла то, что было чрезвычайно большой исходной базой (100 - 200 разработчиков были на проекте) довольно хорошо поддерживаемыми.

Ответ 3

В настоящее время мы тестируем покрытие с помощью EMMA в качестве плагина maven. Это довольно пятно. Он точно скажет вам, сколько вашего кода выполняется вашими тестами. Мы используем JUnit для тестирования.

Ответ 4

Я нахожу Type Rank и метрики кода метода Ранга чрезвычайно полезными, когда вам нужно получить краткий обзор типов ключей/методов в вашем коде. Тип и метод Rank вдохновлен знаменитым алгоритмом ранжирования страницы Google.

Если вы находитесь в среде .NET, NDepend будет вычислять рейтинг рангов и рангов типа для вас (а также 80 другие показатели кода)

Ответ 6

Существует довольно много научной литературы по этому вопросу. Обследование можно найти в тезис Nachiappan Naggapan (Извините, я не смог найти лучший доступ к тезису). Другая презентация по метрикам программного обеспечения здесь.

Я узнал о некоторых показателях, таких как метрика потока информации Генри и Кафуры, после того, как я недавно запустил CCCC на базе кода на С++. CCCC является открытым исходным кодом и выводит исчерпывающий результат (образец), состоящий из 2-3 разных показателей.

Ответ 7

  • Lint
  • Цикломатическая сложность
  • К сожалению, немного больше

Ответ 8

Я регулярно использую Sloccount Дэйва Уилера, который дает LoC, а также пробовал CCCC, хотя он немного устарел.

Ответ 9

В Bell мы вычисляли Функциональные точки для всех проектов (см. IFPUG).

Хорошо: они создали довольно большую базу данных о стоимости проекта.

Плохо: он не работал, как только появилось что-то новое - и поскольку информатика развивается очень быстро, почти каждый раз что-то новое...

Заключение: показатели довольно хороши в постоянных средах. Но если вы измените некоторые параметры, они несколько бесполезны.

Sylvain.

Ответ 10

Я экспериментировал с плагин Metrics для Eclipse из StateOfFlow, и мне нравится идея анализа моего кода. Конечно, не все показатели слишком ясны для меня или полезны, но из широкого спектра различных показателей, которые предоставляет плагин (в настоящее время 14, по моему счету), я склонен относиться к этому серьезно:

Метрики метода: Cyclomatic complex | Количество заявлений | Количество локальных жителей в области | Количество уровней

Показатели класса: количество полей | Взвешенные методы для каждого класса

Чтобы еще больше уменьшить этот список, я действительно верю в меру McCabe Cyclomatic Complexity, и я считаю, что количество заявлений также является весьма полезным показателем слишком большой работы, выполняемой в одном месте.

Из остальных показателей, предоставляемых плагином, я нахожу, что те из недостатков сплоченности в группе методов довольно трудно понять. Сегодня я начал с небольшого эксперимента, и после нескольких часов кодирования я включил поддержку Metrics для проекта. Найденные проблемы 6/7 связаны с единством, особенно удивительным: отсутствие сцепления в методах (общая корреляция) составляет 209%.

Мне сложно что-то сделать: Chidamber и Kemerer | Хендерсон-Продавцы | Общая корреляция | Pairwise Field Irrelation. Я очень склонен поднять допустимые максимумы для этих показателей, поэтому они перестанут появляться в качестве предупреждений.

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

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

Ответ 11

Существенная циклометрическая сложность является интересной, а также дает представление о том, как "неструктурирован" код.

Неструктурированный код - это использование разрывов и переходов, например, для выхода из структур управления, например, для циклов.

Однако единственный продукт, который я знаю об этом, дает эту метрику McCabe IQ