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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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