问软件质量的客观度量

EN

这是个危险的主意。质量的“客观”代理直接导致管理奖励，开发人员将以牺牲实际质量为代价追求这些指标。

这就是意外后果的规律。

质量--虽然很重要--只是软件的一个小方面。软件创造的功能和价值远比质量重要得多。

所有的度量都会导致活动来优化度量。这反过来又会产生你可能不喜欢的后果。

软件非常复杂。很难理解它有多复杂。

即使像单元测试代码覆盖这样“明显”的事情也会浪费时间。要达到100%，可能需要创建比正在测试的普通代码更复杂的测试。获得100%的保险可能涉及不可接受的成本。对于琐碎的、小的、很少使用的代码，另一种选择是通过检查进行测试。但这不符合100%的标准游戏。

另一个例子是圈复杂度。它是衡量代码质量的最佳方法之一。但是，它可以通过创建许多比一个更大的函数更难阅读(也更难维护)的小函数来实现。在代码评审中，您会一致认为它可能不是很容易读，但它满足了复杂性阈值。

我还想知道这是否是一个危险的想法，如果质量的客观代理变得流行，那么业务压力将导致开发人员以牺牲整体质量(那些质量方面不被代理度量)为代价来追求这些度量标准。

是的，没有“如果”。这被称为“测量功能障碍”，并已观察和写了许多次乔尔在2002年写了一篇文章.参考一本书的哈佛教授。

这并不意味着这些度量是无用的，只是人们永远不应该将激励或政策明确地建立在这样的代理度量之上。如果您想提高质量，那么一个值很差的代理度量可能是一个很好的起点。但是，您不能仅仅因为您的所有指标都具有巨大的价值而得出质量是好的结论。

我感兴趣的是与类型的网络(或图形)及其相互关系相关的一种更深层次的质量形式，即每种类型所指的类型是什么类型，是否存在与适当分层体系结构相关的明确可识别的互连集群，或者相反，是否存在一个大的类型引用“球”(“单块”代码)。

这听起来像是扇形和扇形。扇入计数调用给定模块的模块数量，扇出计数由给定模块调用的模块数。要使用的警告标志是具有大扇入和大扇出的模块，因为这可能表明设计很差，也是重构或重新设计的关键目标。

此外，每种类型和/或方法的大小(例如，以Java字节码或.Net IL的数量来衡量)应该给出一些指示，说明如何将大型复杂算法作为整体代码块来实现，而不是将其分解为更易于管理/可维护的块。

一个简单的度量将是代码行。您可以将其分解为贯穿整个项目的代码行和每个模块的代码行(可能使用不同大小的模块)。您可以使用它作为警告指示符，指示您应该检查特定模块。一本关于软件质量度量的书讨论了一些工作，指出缺陷率和模块大小之间的关系是曲线的，其中每个KSLOC的平均缺陷与模块的大小在175-350SLOC之间。

更复杂的是圈复杂度，它旨在表示系统的可测试性、可理解性和可维护性。圈复杂度计算通过应用程序或模块的独立路径数。测试的数量，以及产生和执行测试所需的精力，都与圈复杂度密切相关。

我怀疑，高质量和低质量之间的确切阈值/决策点是主观的，例如，由于可维护性指的是人类程序员的可维护性，因此功能分解必须与人类思维的工作方式相兼容。

我不确定情况是否如此。

例如，有研究表明，人类的工作记忆只能容纳7个正负2个物体。这可能对测量风扇输入和扇出感兴趣--如果我在一个模块中工作，并且它与超过7个其他模块相连，我可能无法准确地跟踪其他模块在我脑中的位置。

还有一些工作是将缺陷与度量指标(如圈复杂度)联系起来。由于您希望最小化系统中的缺陷，所以可以确定需要进行更多测试或重构的点，这是由高度圈复杂度确定的。

我还想知道这是否是一个危险的想法，如果质量的客观代理变得流行，那么业务压力将导致开发人员以牺牲整体质量(那些质量方面不被代理度量)为代价来追求这些度量标准。

任何度量或度量都是这样的。他们需要被用来理解系统和作出明智的决定。“你无法管理你无法衡量的东西”这句话浮现在脑海中。如果您想要高质量的软件，您需要一些度量和度量来评估该质量。然而，这也有另一面。你不能只靠数字来管理。你可以用数字来做出明智的决定，但你不能仅仅因为数字这么说就做出决定。