Объективные показатели качества программного обеспечения [закрыто]

12

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

Меня интересует более глубокая форма качества, связанная с сетью (или графиком) типов и их взаимосвязью, то есть к каким типам относится каждый тип, существуют ли четко идентифицируемые кластеры взаимосвязанности, относящиеся к многоуровневая архитектура или, наоборот, существует большой «шар» ссылок на типы («монолитный» код). Кроме того, размер каждого типа и / или метода (например, измеренный в количестве байтового кода Java или .Net IL) должен давать некоторое представление о том, где большие сложные алгоритмы были реализованы как монолитные блоки кода, вместо того, чтобы разлагаться на более управляемые / обслуживаемые ломти.

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

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

Еще один способ думать о качестве - с точки зрения энтропии. Энтропия - это тенденция систем переходить из упорядоченного в неупорядоченное состояние. Любой, кто когда-либо работал в реальном, среднем и крупномасштабном программном проекте, оценит степень, в которой качество кодовой базы со временем ухудшается. Деловые нагрузки обычно приводят к изменениям, которые фокусируются на новых функциональных возможностях (за исключением тех случаев, когда само качество является основным преимуществом, например, в программном обеспечении для авионики), а также на ухудшении качества из-за проблем регрессии и функциональности «чистокровных», где оно не подходит перспективы качества и обслуживания. Итак, можем ли мы измерить энтропию программного обеспечения? И если да, то как?

redcalx
источник
Я согласен с С. Лоттом. В жизни часто существует разница между «как это должно быть» и «как оно есть». Боже, я бы хотел, чтобы больше людей на этой планете преодолели свой подход «благих намерений» и усердно смотрели на «как это». Помимо неправильных стимулов, будет опасное ложное чувство безопасности. Объедините это с людьми, пытающимися играть в систему (что естественно, потому что они ВСЕГДА пытаются улучшить свои условия (денежные или другие)), и вы получите дерьмовую ситуацию. Неудивительно, что рыночные сбои «раз в тысячелетие» происходят каждые два десятилетия.
Работа

Ответы:

20

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

Это закон непреднамеренных последствий.

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

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

Программное обеспечение очень сложное. Трудно понять, насколько это по-настоящему сложно.

Даже такие «очевидные» вещи, как покрытие кода модульного теста, могут тратить время. Достижение 100% может потребовать создания тестов, которые на самом деле являются более сложными, чем простой тестируемый код. Получение 100% покрытия может повлечь за собой неприемлемую стоимость. [Альтернатива для тривиального, небольшого, редко используемого кода - проверка за проверкой. Но это не соответствует метрической игре на 100%.]

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

С. Лотт
источник
3
«Все метрики приводят к активности по оптимизации метрики». Я думаю, что это слишком часто правда. Однако этого не должно быть. Метрики должны, как я упоминал в моих последних параграфах, направлять управление. Слишком часто, однако, решения принимаются исключительно потому, что для чисел, без понимания значения чисел и рисков и компромиссов, связанных с решением.
Томас Оуэнс
3
«Однако этого не должно быть». Объясните, каким образом можно сказать людям не оптимизировать свои вознаграждения. Найдите один пример человеческого поведения, в котором культурные награды (основанные на всевозможных сумасшедших социальных структурах) не являются первичными, первостепенными и самыми важными вещами, которые люди будут преследовать. Все, что включает в себя «должен» или «не должен», должно быть сопоставлено с тем, что на самом деле делают люди. Они действительно оптимизируют свои награды. Если показатели являются частью вознаграждения, люди оптимизируют показатели. Пожалуйста, не используйте «должен» для описания поведения людей.
С.Лотт
2
@ Томас Оуэнс: «У вас просто нет вознаграждений для оптимизации на основе метрик». Забавно. Как вы будете держать их в секрете? Как только я узнаю, что ваш код был принят раньше, чем мой, я хочу узнать, как руководство решило, что ваш модуль выполнен, а мой - нет. Как только я найду метрику, которая «руководит» этим решением, я полностью разберусь с метрикой, чтобы сделать ее уже на ранней стадии. Если нет метрики, в которую я могу играть, тогда я увижу, что решение было произвольным, руководство любит вас больше, чем я, и я уйду, потому что нет никакого стандарта производительности, который я мог бы воспринимать.
С.Лотт
2
@ Томас Оуэнс: «Я никогда не видел, чтобы показатели приводили к вознаграждениям». Культурные стимулы существуют во всех ситуациях, когда два или более человека работают вместе. «Люди признаны за их работу». Метрика цикломатической сложности становится целью. Если вы достигаете своей цели цикломатической сложности быстрее, чем я, тогда есть культурные награды: вы более «продуктивны», чем я. Мне нужно, чтобы моя метрика сложности выглядела так же «продуктивно», как и вы.
S.Lott
2
@ Томас Оуэнс: «Это вопрос личной гордости». Это отличный пример системы культурных вознаграждений. Метрики могут исказить это из-за непреднамеренных последствий возможности создания красивого показателя, который не соответствует хорошему коду. Вы предоставили отличный пример культурных наград, которые могут быть искажены метриками.
S.Lott
4

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

Бинго, и нет «если» об этом. Это называется «дисфункция измерения», и ее неоднократно наблюдали и писали Джоэл в 2002 году, ссылаясь на книгу профессора Гарварда.

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

Майкл Боргвардт
источник
3

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

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

Кроме того, размер каждого типа и / или метода (например, измеренный в количестве байтового кода Java или .Net IL) должен давать некоторое представление о том, где большие сложные алгоритмы были реализованы как монолитные блоки кода, вместо того, чтобы разлагаться на более управляемые / обслуживаемые ломти.

Простым измерением были бы строки кода. Вы можете разбить его на общее количество строк кода по всему проекту и количество строк кода на модуль (возможно, с использованием модулей разных размеров). Вы можете использовать это в качестве предупреждающего индикатора, указывающего, что вы должны просмотреть определенные модули. В книге по измерениям и показателям качества программного обеспечения обсуждается некоторая работа, которая указывает на то, что соотношение между частотой дефектов и размером модуля является криволинейным, где средний дефект на KSLOC поставляется с модулями с размером от 175 до 350 SLOC.

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

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

Я не уверен, что это так.

Например, было проведено исследование, которое предполагает, что рабочая память человека может содержать только 7 плюс / минус 2 объекта . Это, вероятно, представляет интерес для измерения разветвления и разветвления - если я работаю в модуле, и он подключен к более чем 7 другим модулям, я, вероятно, не смогу точно отслеживать, что это за модули. другие модули в моей голове.

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

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

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

Томас Оуэнс
источник
Особенность разветвления / разворота в том, что он дает два числа на модуль / класс (или что-то еще) и поэтому игнорирует некоторые более глубокие организационные структуры, связанные с подключением модулей. Например, у вас может быть небольшой кластер высокосвязанных модулей, связанных с логическим уровнем, и вы ожидаете, что соединения между уровнями будут минимальными (по сравнению), представляя четко определенный интерфейс / контракт между уровнями. Я полагаю, что мы рады, что некоторые модули тесно связаны (например, обычно используемые вспомогательные методы / классы), но в зависимости от «структуры» связности (это моя гипотеза).
Redcalx
@locster Вы, вероятно, хотите расширить его и отметить, например, какие пакеты классов, к которым вы подключены, находятся. Не просто смотрите на необработанные числа, но разбивайте их на такие вещи, как классы X в моем пакете, Y классы вне моего пакета, или Z классы в этом конкретном пакете. Если вы видите разветвление между модулями в вашей модели данных и модулями в вашем пользовательском интерфейсе, это может быть индикатором проблемы. Вы должны копать немного глубже, чем просто необработанные цифры.
Томас Оуэнс
3

Есть метрики или прокси для многих интересующих вас качеств:

  1. Строки кода
  2. Веер, веер
  3. Коэффициент ошибок на 1000 строк кода
  4. Цикломатическая сложность
  5. Покрытие кода
  6. Охват точки принятия решения
  7. Соотношение ошибок, исправленных / внесенных обслуживанием
  8. Анализ функциональных точек

Есть некоторые проблемы со всеми этими пунктами:

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

Общий эффект этих проблем заключается в том, что такие метрики, вероятно, будут полезны только в рамках более широкой культуры - таких как TQM, обеспечение качества (не контроль), постоянное улучшение, кайдзан и т. Д. Необходимо определить элементы как культуры и как это нужно изменить. Если у вас есть их определение, то такие метрики становятся важными инструментами, помогающими улучшить качество кода, методы работы, производительность и т. Д. Без этого более широкого контекста метрики будут генерировать работу для оптимизации метрики; станет инструментом банка для повышения производительности и снижения затрат; и станет препятствием для игры со стороны разработчиков.

Крис Уолтон
источник
2

Вы можете быть одержимы метриками, или вы можете быть одержимы лучшими людьми, инструментами, практиками для проектирования и контроля качества, которые вы можете себе позволить. Я был бы намного счастливее, если бы у меня было несколько параноидальных гениев QA, которые читали «Обманутый случайностью» и которые хотели бы автоматизировать, а не кучу красиво отформатированных отчетов с числами.

работа
источник
+1 для ссылки на книгу Нассима Талеба. Ошибочные рассуждения / эпистемология находятся в цепочке причинно-следственных связей низкого качества.
Redcalx
@locster, твой комментарий заставил меня задуматься над оператором конвейера F # :). Вы начинаете с «Справочника Нассима Талеба», но заканчиваете «цепочкой причинно-следственных связей низкого качества» (вместо «цепочки причинно-следственных связей низкого качества»). Точно так же, как в английском мы иногда хотели бы иметь два способа сказать что-то, мы могли бы предпочесть это и на языке программирования.
Работа
1

Есть эта фундаментальная проблема с метриками.

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

Это то, что убило метрики Холстеда еще в 1970-х годах. (Однажды, около 1978 года, я случайно заговорил с новым доктором наук о метриках Холстеда, в котором он указал на это.)

Совсем недавно было показано, что цикломатическая сложность МакКейба очень сильно коррелирует с необработанным SLOC, до такой степени, что парень, который проводил исследование, громко удивился, если метрика МакКейба говорит нам что-нибудь полезное вообще.

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

Джон Р. Штром
источник
Чтобы его можно было поддерживать, нам нужно, чтобы код был в виде кусков человека, поэтому метрика SLOC выглядит довольно хорошо с этой точки зрения. Однако, для данного размера у вас может быть различное количество уникальных путей (в зависимости от цикломатической сложности), и я бы сказал, что большее количество путей - это прокси для менее понятных. Следовательно, я бы сказал, что CC, вероятно, добавляет / некоторые / дополнительные значения к SLOC, при условии, что вы допускаете некоторую гибкость, исключения из правила и т. Д. То есть строго не применяйте CC.limits / цели.
Redcalx
1
@locster: Учитывая два 100 модулей SLOC, у одного с СС 47, вероятно, будет больше проблем, чем у одного с СС 3. ОДНАКО, для большого кода реального мира, можно обнаружить, что короткие модули имеют тенденцию иметь низкий CC и длинные модули, как правило, имеют высокий CC, так что знание SLOC дает вам очень хорошее предположение о CC, и наоборот. Это то, что подразумевается под «очень сильно коррелированными». ТАКИМ ОБРАЗОМ, в реальном коде любая выгода, которую вы получите, заметив CC = 47, БОЛЕЕ ЛЕГКО получится, заметив SLOC = 1500. (Числа вытащены случайным образом, принцип тот же.)
Джон Р. Стром,
Да, я согласен, что они будут иметь сильную корреляцию, хотя отношения, как правило, нелинейны. например, оценка СС примерно равна LOC, повышенному до некоторой степени. Таким образом, с психологической точки зрения, показатель CC может стать очень большим и очень быстрым, тогда как соответствующий показатель SLOC кажется «только немного выше». Да, я знаю, что я хватаюсь за соломинку здесь :)
Redcalx
@locster: Я занимаюсь этим более 30 лет. В эти дни я обычно вижу рутинные процедуры потока сознания, которые продолжаются в течение нескольких сотен SLOC, без всякой причины. За все эти годы я видел ровно одну (1) подпрограмму, которая фактически ДОЛЖНА быть более чем одной страницей кода принтера (около 60 строк). Все остальное могло быть довольно выгодно скомпоновано, а читаемость и надежность значительно возросли. (Это не считается большими государственными машинами. Они могут быть проблемой в этой области, но они РЕДКО.)
Джон Р. Стром
-2

Учитывая все остальные ответы здесь, я чувствую себя немного глупо с этим маленьким. Взгляните на Crap4j , который пытается ранжировать методы в java по тому, насколько они воняют. (Проект выглядит заброшенным.)

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

Шон Макмиллан
источник