软件质量的客观指标[关闭]

在软件产品中可以测量各种类型的质量，例如，目的（例如最终用途）的适用性，可维护性，效率。其中一些在某种程度上是主观的或特定于领域的（例如，良好的GUI设计原则可能因文化而异，或取决于使用情况，请考虑军事还是消费者使用）。

我感兴趣的是与类型的网络（或图形）及其相互关联性的更深层次的质量形式，也就是说，每种类型所指的是什么类型，是否存在与适当类型有关的清晰可识别的互连性集群。分层体系结构，或者相反，存在大量的类型引用“整体”（“整体”代码）。同样，每种类型和/或方法的大小（例如，以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，质量保证（而非控制），持续改进，改进等。必须定义两种文化的元素，以及需要如何更改。如果您具有这些定义，那么诸如此类的度量就将成为帮助提高代码质量，工作实践，生产率等的基本工具。将成为beancounter的工具，以提高生产力并降低成本；并将成为开发人员的游戏障碍。

您可能沉迷于指标，或者沉迷于可以负担的最好的人员，工具，工程实践和质量保证。如果我有几位偏执的QA天才们，他们会读过“随机性愚弄”，并且喜欢自动化而不是一堆带有数字的格式精美的报告，那我会更加高兴。

指标存在这个基本问题。

在现实世界中的真实代码中，几乎所有建议的度量标准都已显示出与原始SLOC（代码源代码行）紧密相关或非常紧密相关。

这就是1970年代扼杀Halstead的指标的原因。（大约在1978年的某一天，我参加了一位新博士关于Halstead度量标准的演讲，他指出了这一点。）

最近，事实证明，McCabe的圈复杂度与原始SLOC密切相关，以至于进行这项研究的人大声怀疑McCabe的度量标准是否告诉我们任何有用的东西。

几十年来，我们已经知道，大型程序比小型程序更有可能出现问题。几十年来，我们已经知道，大型子例程比小型子例程更容易出错。当查看分布在一张桌子上的四个打印机页面时，为什么我们需要奥秘的指标来告诉我们呢？

在这里给出所有其他答案时，我对这个小答案感到很傻。看一眼 Crap4j，它试图根据JavaJava方法中的臭味来对其进行排名。（该项目看起来已被放弃。）

它结合了圈复杂度和测试覆盖率。像其他所有指标一样，它也是可玩的。