Существуют различные типы качества, которые можно измерить в программных продуктах, например, соответствие назначению (например, конечное использование), ремонтопригодность, эффективность. Некоторые из них в некоторой степени субъективны или специфичны для конкретной области (например, хорошие принципы разработки графического интерфейса пользователя могут различаться в зависимости от культуры или в зависимости от контекста использования, например, военное и потребительское использование).
Меня интересует более глубокая форма качества, связанная с сетью (или графиком) типов и их взаимосвязью, то есть к каким типам относится каждый тип, существуют ли четко идентифицируемые кластеры взаимосвязанности, относящиеся к многоуровневая архитектура или, наоборот, существует большой «шар» ссылок на типы («монолитный» код). Кроме того, размер каждого типа и / или метода (например, измеренный в количестве байтового кода Java или .Net IL) должен давать некоторое представление о том, где большие сложные алгоритмы были реализованы как монолитные блоки кода, вместо того, чтобы разлагаться на более управляемые / обслуживаемые ломти.
Анализ, основанный на таких идеях, может быть в состоянии рассчитать показатели, которые по крайней мере являются показателем качества. Я предполагаю, что точный порог / точки принятия решения между высоким и низким качеством был бы субъективным, поскольку под ремонтопригодностью мы подразумеваем ремонтопригодность программистов-людей и, следовательно, функциональная декомпозиция должна быть совместима с тем, как работает человеческий разум. Поэтому я задаюсь вопросом, может ли когда-либо существовать математически чистое определение качества программного обеспечения, которое превосходит все возможные программы во всех возможных сценариях.
Мне также интересно, если это опасная идея, что, если объективные прокси для качества станут популярными, деловое давление заставит разработчиков использовать эти метрики в ущерб общему качеству (те аспекты качества, которые не измеряются прокси).
Еще один способ думать о качестве - с точки зрения энтропии. Энтропия - это тенденция систем переходить из упорядоченного в неупорядоченное состояние. Любой, кто когда-либо работал в реальном, среднем и крупномасштабном программном проекте, оценит степень, в которой качество кодовой базы со временем ухудшается. Деловые нагрузки обычно приводят к изменениям, которые фокусируются на новых функциональных возможностях (за исключением тех случаев, когда само качество является основным преимуществом, например, в программном обеспечении для авионики), а также на ухудшении качества из-за проблем регрессии и функциональности «чистокровных», где оно не подходит перспективы качества и обслуживания. Итак, можем ли мы измерить энтропию программного обеспечения? И если да, то как?
источник
Ответы:
Это опасная идея. «Объективные» показатели качества напрямую ведут к вознаграждениям руководства, и разработчики будут использовать эти показатели за счет фактического качества.
Это закон непреднамеренных последствий.
Качество - хотя и важно - это только один маленький аспект программного обеспечения. Функциональность и ценность, создаваемые программным обеспечением, гораздо важнее качества.
Все метрики приводят к активности по оптимизации метрики. Это, в свою очередь, имеет последствия, которые вам могут не понравиться.
Программное обеспечение очень сложное. Трудно понять, насколько это по-настоящему сложно.
Даже такие «очевидные» вещи, как покрытие кода модульного теста, могут тратить время. Достижение 100% может потребовать создания тестов, которые на самом деле являются более сложными, чем простой тестируемый код. Получение 100% покрытия может повлечь за собой неприемлемую стоимость. [Альтернатива для тривиального, небольшого, редко используемого кода - проверка за проверкой. Но это не соответствует метрической игре на 100%.]
Другой пример - цикломатическая сложность. Это один из лучших показателей качества кода. Но это может быть реализовано путем создания множества небольших функций, которые труднее читать (и труднее поддерживать), чем одну большую функцию. Вы попадаете в обзоры кода, где соглашаетесь, что он может быть не очень читабельным, но соответствует порогу сложности.
источник
Бинго, и нет «если» об этом. Это называется «дисфункция измерения», и ее неоднократно наблюдали и писали Джоэл в 2002 году, ссылаясь на книгу профессора Гарварда.
Это не означает, что такие метрики бесполезны, просто никогда не следует явно основывать стимулы или политики на таких прокси-измерениях. Если вы хотите улучшить качество, лучше всего начать с прокси-метрики с очень плохим значением. Но вы не можете сделать вывод, что качество хорошее только потому, что все ваши показатели имеют хорошие значения.
источник
Это звучит как фан-ин и фан-аут. Разветвление подсчитывает количество модулей, вызывающих данный модуль, а разветвление подсчитывает количество модулей, вызываемых данным модулем. Предупреждающим знаком для использования могут быть модули с большим и большим разветвлениями, поскольку это может указывать на плохой дизайн и ключевую цель для рефакторинга или перепроектирования.
Простым измерением были бы строки кода. Вы можете разбить его на общее количество строк кода по всему проекту и количество строк кода на модуль (возможно, с использованием модулей разных размеров). Вы можете использовать это в качестве предупреждающего индикатора, указывающего, что вы должны просмотреть определенные модули. В книге по измерениям и показателям качества программного обеспечения обсуждается некоторая работа, которая указывает на то, что соотношение между частотой дефектов и размером модуля является криволинейным, где средний дефект на KSLOC поставляется с модулями с размером от 175 до 350 SLOC.
Что-то более сложное - это цикломатическая сложность, которая предназначена для указания на тестируемость, понятность и ремонтопригодность системы. Цикломатическая сложность подсчитывает количество независимых путей через приложение или модуль. Количество тестов и, следовательно, усилия, необходимые для их создания и выполнения, тесно связаны с цикломатической сложностью.
Я не уверен, что это так.
Например, было проведено исследование, которое предполагает, что рабочая память человека может содержать только 7 плюс / минус 2 объекта . Это, вероятно, представляет интерес для измерения разветвления и разветвления - если я работаю в модуле, и он подключен к более чем 7 другим модулям, я, вероятно, не смогу точно отслеживать, что это за модули. другие модули в моей голове.
Также была проведена работа по сопоставлению дефектов с такими показателями, как цикломатическая сложность. Поскольку вы хотите минимизировать дефекты в вашей системе, вы можете идентифицировать точки, которые требуют более тщательного тестирования или рефакторинга, что определяется высокой цикломатической сложностью.
Это касается любых измерений или метрик. Их необходимо использовать для понимания системы и принятия обоснованных решений. На ум приходит фраза «Вы не можете управлять тем, что не можете измерить». Если вы хотите высококачественное программное обеспечение, вам нужны некоторые измерения и метрики для оценки этого качества. Однако в этом есть обратная сторона. Вы не можете управлять исключительно по номерам. Вы можете использовать цифры для принятия обоснованных решений, но вы не можете принять решение только потому, что цифры говорят так.
источник
Есть метрики или прокси для многих интересующих вас качеств:
Есть некоторые проблемы со всеми этими пунктами:
Общий эффект этих проблем заключается в том, что такие метрики, вероятно, будут полезны только в рамках более широкой культуры - таких как TQM, обеспечение качества (не контроль), постоянное улучшение, кайдзан и т. Д. Необходимо определить элементы как культуры и как это нужно изменить. Если у вас есть их определение, то такие метрики становятся важными инструментами, помогающими улучшить качество кода, методы работы, производительность и т. Д. Без этого более широкого контекста метрики будут генерировать работу для оптимизации метрики; станет инструментом банка для повышения производительности и снижения затрат; и станет препятствием для игры со стороны разработчиков.
источник
Вы можете быть одержимы метриками, или вы можете быть одержимы лучшими людьми, инструментами, практиками для проектирования и контроля качества, которые вы можете себе позволить. Я был бы намного счастливее, если бы у меня было несколько параноидальных гениев QA, которые читали «Обманутый случайностью» и которые хотели бы автоматизировать, а не кучу красиво отформатированных отчетов с числами.
источник
Есть эта фундаментальная проблема с метриками.
Было показано, что практически все предложенные метрики в реальном мире для реального кода сильно или очень сильно коррелируют с необработанным SLOC (исходными строками кода).
Это то, что убило метрики Холстеда еще в 1970-х годах. (Однажды, около 1978 года, я случайно заговорил с новым доктором наук о метриках Холстеда, в котором он указал на это.)
Совсем недавно было показано, что цикломатическая сложность МакКейба очень сильно коррелирует с необработанным SLOC, до такой степени, что парень, который проводил исследование, громко удивился, если метрика МакКейба говорит нам что-нибудь полезное вообще.
Мы десятилетиями знали, что у больших программ больше проблем, чем у маленьких. В течение десятилетий мы знали, что большие подпрограммы, скорее всего, содержат ошибки, чем маленькие. Зачем нам нужны загадочные метрики, чтобы сказать нам это, если смотреть на четыре страницы принтера, разложенные на столе, должно быть достаточно убедительно?
источник
Учитывая все остальные ответы здесь, я чувствую себя немного глупо с этим маленьким. Взгляните на Crap4j , который пытается ранжировать методы в java по тому, насколько они воняют. (Проект выглядит заброшенным.)
Он использует комбинацию цикломатической сложности и тестового покрытия. Как и любой другой показатель, это играбельно.
источник