您如何根据经验指标判断软件的好坏？

目前，我被要求看一个项目，该项目在五个月前完成了核心开发，但是仍然存在大量缺陷。对于大约每10个已修复的缺陷而言，所发生的事情是，我们提出至少4个缺陷，在某些情况下会提出8个缺陷。

我相信供应商的编码实践很差，并且对此达成了普遍共识。但是，我想知道软件是否存在结构性问题？缺陷密度是一种有用的措施，但是如果核心软件编写不当，则更多的是卖方正在做的所有事情都在转移问题。

在基础架构中，如果某些东西构建得不好，则可以更明确地定义，除了LOC缺陷之外，您还可以对软件使用哪些度量？

该产品已进入缺陷修复阶段4个月，但仍未解决足够的关键缺陷。我们不会注入新功能，而只是解决回归问题。

这表明开发质量问题尚未解决。但是，如果产品本身存在根本缺陷，那就是另一个问题。考虑到核心代码库编写得不好并且文档有限，所有外部开发人员正在做的事情正在将问题从A转移到B。一旦内部开发团队接手我，我担心他们将不得不从根本上重写代码以将其替换为B。使它起作用。

因此，当您接受第三方提供的产品并要求其提供支持时，您将使用什么接受标准来定义标准？

除了让我们的首席开发人员对每个版本的代码进行同行评审之外，还不确定还能做什么？

你不知道

很难客观地衡量软件质量。很难，没有解决方案。我不想在这个答案中涉足是否可以找到解决方案的问题，而只是指出为什么定义一个解决方案真的很难。

按现状推理

正如Kilian Foth所指出的那样，如果有一种简单的方法来衡量“优质”软件，那么我们所有人都会使用它，并且每个人都会要求它。

在某些项目中，管理人员决定实施某些指标。有时它起作用，有时却没有。我不知道有任何重大关联。特别是关键的系统软件（例如飞机，汽车等）对“确保”软件质量有很多度量要求-我不知道有任何研究表明这些要求实际上会带来更高的质量，并且我对相反。

通过反情报推理

Kilian也已经暗示过，更普遍的说法是“可以并将会使用每个度量”。

衡量指标是什么意思？对于开发人员而言，这是一个有趣的游戏：您可以确保指标值看起来确实不错，同时还能做得很烂。

假设您根据LOC测量缺陷。我该怎么玩？简单-只需添加更多代码！编写愚蠢的代码，导致超过100行无法执行操作，并且每个LOC的缺陷数量突然减少。最重要的是：您实际上是通过这种方式降低了软件质量。

滥用工具的缺点，将其定义扩展到最大，发明了全新的方法。.基本上，开发人员是非常聪明的人，并且如果您的团队中只有一个开发人员具有很有趣的指标，那么您的指标将是可疑的。

这并不是说指标总是不好的-团队对这些指标的态度至关重要。特别是，这意味着对于任何分包商/第三方供应商关系，它都无法正常工作。

定位错误的原因

您要衡量的是软件质量。您要衡量的是一个或多个指标。

在您衡量的内容与您认为会告诉您的内容之间存在差距。这个差距甚至很大。

它始终在我们周围的所有企业中发生。是否曾根据KPI（关键绩效指标）做出过决策？这是同样的问题-您想要一家公司做得很好，但是您需要衡量其他事情。

通过量化推理

指标可以测量。这是我们完全与他们打交道的唯一原因。但是，软件质量超出了这些可衡量的实体的范围，并且有很多难以量化的方面：源代码的可读性如何？您的设计有多可扩展性？新团队成员入职有多难？等等等

仅通过度量标准来判断软件质量，而对您无法量化的质量部分视而不见，肯定是行不通的。

编辑：

摘要

我要指出的是，以上全部内容都是根据指​​标客观地判断软件的优劣。这意味着，它没有说明您是否以及何时应应用指标。

实际上，这是一个单向的含义：错误的指标意味着错误的代码。单向意味着错误代码不能保证错误的度量标准，也不能保证良好的度量标准可以保证好的代码。另一方面，这本身意味着您可以应用度量标准来判断软件-当您牢记这一含义时。

您对软件A进行了度量，结果表明度量标准确实很差。这样就可以确定代码质量不好。您对软件B进行了测量，并且度量标准还可以，那么您对代码质量一无所知。当实际上只是“代码良好=>指标良好”时，不要愚弄“标准良好=代码良好”。

从本质上讲，您可以使用指标来发现质量问题，而不是质量本身。

是的，您可以通过一定程度地查看指标来判断代码是否存在质量问题。

更具体地说，在代码库上运行复杂性分析工具，您将了解代码的好坏。

例如，您可以运行source monitor。

这将告诉您代码的复杂程度。我可以告诉您我遇到的每个有问题的系统都有不好的数字。10到100s方法的复杂度远远超过可接受的范围。糟糕的数字。可怕的复杂性，嵌套，深度等。这将导致很多问题，持续的高缺陷率，难以进行更改而又不会破坏其他内容等。

另一件事是缺陷。随着时间的流逝，系统应该稳定下来。理想情况下，新缺陷应趋向于零或趋于平坦，这意味着新缺陷和当前缺陷应随时间减少。

该图应如下所示：

随着时间的推移出现缺陷

如果它们保持不变或增加，则该软件不好。您只有4个月的时间，所以我会再给您几个月到一年的时间。经过6个月到一年的时间，如果您不断出现缺陷，那么质量就会很差。您的团队开发了另一个泥球。

下一步测试。你有吗？如果没有的话，那么质量就会下降，漏洞更多，客户流失率会更高。如果有它们，代码覆盖率之类的指标可以很好地了解所覆盖的代码量，但是它不能衡量质量。我见过很好的代码覆盖率数字，但实际测试却很糟糕。他们没有测试系统的任何行为或功能。开发人员只是在编写它们，以改善管理指标。因此，您必须进行测试，而且测试必须出色。 代码覆盖率指标本身并不是质量的指标。

代码审查，您正在执行吗？如果没有，质量会降低。这对于初级开发人员尤其重要。如果您敏捷，只需在您的故事中添加一个代码审查任务，即“代码审查”。如果管理层想跟踪数字，您将需要一个跟踪评论的工具，例如Crucible。我认为代码复核数字或指标在这里并不重要，除了它们应该是您的过程的一部分这一事实。并非每个签入都需要审查。但是，审阅可以帮助确保人们不会重新发明轮子或编写别人无法理解和/或维护的代码。

最后，您只需要评估代码，没有任何度量标准可以提供帮助。每个有问题的代码项目都具有以下特征：

• 数据结构不良。一切都是字符串，或者XML随处传递和解析，上帝对象或不必要的复杂或通用数据结构，没有域模型。
• 缺乏组织或结构，任何不重要的项目都应具有某种划分或分层，以将逻辑分开。 在这里看看 ...如果您没有看到这种类型的组织或分离（到处都是逻辑混合），那么系统将很难维护和理解。
• 过度抽象。有时反之亦然，系统过于抽象。如果所有内容都是接口和抽象类，或者您必须浏览大量的“包装”类型类，则质量会很差，因为新开发人员将无法浏览对象膨胀。
• 难以理解的代码。如果您是一位经验丰富的开发人员，并且正在查看难以理解的代码，那么它将存在质量问题。我的个人指标是，如果我正在查看代码，但很难遵循或使我感到愚蠢，或者我感觉自己在浪费大量的脑循环来弄清楚逻辑，那么这就是不好的代码。如果经验丰富的开发人员很难追随，那就想像一下新开发人员的情况。他们会引入问题。

我的建议是对代码进行复杂性分析。不要共享结果，而是对结果进行后续的独立调查（查看代码），并确定代码库的总体运行状况。由此，制定一个行动计划，并尝试补救一些复杂的代码区域。

度量标准的可悲之处在于，您可能最终会提高度量标准的结果值，而不是旨在提高度量标准的质量...

在Visual Studio中，存在用于将编译器警告视为错误的设置。现在，有些人不了解警告，并且为了编译代码，将使用一些简单的技巧（例如“ pragma disable warning”或向功能/属性添加“ new”关键字来隐藏基础的非虚拟成员）类）。

如果您有权访问源代码，则可以运行静态代码分析。对于.Net项目，您可以使用例如FxCop或ReSharper InspectCode。如果开发团队正确使用了这些工具，它们将有助于提高质量。但是，当然，可以使用一些“修正”来删除警告而不理解它们。

您可以看一下自动化测试/ UnitTest：代码覆盖率如何？但是，仅覆盖率并不能告诉您测试是否实际检查了代码，或者只是执行了一次代码。

追求高质量是一种态度，许多工具及其指标都可以支持这种态度，但是没有开发人员态度的指标就无济于事。

除了收集诸如缺陷注入之类的指标外，您还应该查看的一件事是找出缺陷的来源。通常，它与规范有关。

基本上，这是规范中的错误，是规范中的模棱两可，由植入程序决定还是执行中的错误。

一种更定性的方法是询问软件是否有用？如果您看上去很努力，就会发现任何软件都存在缺陷。但是，如果它能够很好地赚钱，那么可能还不错。

底部，没有办法知道。

对于最初的问题（在获得哲学回答之前）：产品应该做什么并且可以做到吗？仅通过缺陷数/密度进行测量是不够的。我无法确定这是一个库还是一个应用程序，代码库有多大，问题域有多大，缺陷的严重程度如何。例如，根据未正确处理的格式的重要性，不处理123种输入格式之一可能是微不足道的缺陷或显示停止。高水准是总比没有强。

我为这个问题做一个假设：代码和软件之间是有区别的。 我将软件定义为客户/用户用来解决问题的工具，而代码则是软件的基础。

软件只能主观衡量。也就是说，对于软件而言重要的指标是人们是否使用它来解决问题。该指标取决于他人的行为，因此取决于主观。注意：对于某些问题，一个软件可能非常有用，因此被认为是高质量的（用于计算的Excel），但是对于其他问题而言却不是质量的软件（用于播放MP3文件的Excel）。

（通常）可以使用经验指标来衡量代码。但是对于质量的解释不是“是/否”，甚至不是“ 0到N”的范围。指标根据标准进行衡量。因此，度量标准可以找到标准定义的关注领域，但是缺少关注领域并不能证明这是质量代码。例如，有用的指标：是否可以编译？否->质量不高。是-> ???。是否通过单元测试？没有？也许？（因为是单元测试质量代码？），是-> ???。

因此，就像戈德尔的不完全证明所证明的数学公理一样（也就是说，对于任何有限的公理，都存在不能证明是对还是错的数学陈述），我认为我们无法真正回答“这是质量吗？码？' 每一段代码。直观地，软件度量之间可能存在一个映射，以回答质量，数学公理之间存在一个映射，以回答证明是对还是错。

提出这一论点的另一种方法是进入自然语言。威廉·莎士比亚，刘易斯·卡罗尔和马克·吐温都是成功的作家，并因其高质量的作品而受到许多人的喜爱。但是，我们可以采用什么标准的语法，词汇，风格或语音来使它们始终高于随机的12年级学生？而且，尽管有可能为这三个方法制定一些综合措施，但它将如何评价《约翰书》（JJ），托尔金（JRR Tolkien），荷马（Homer），塞万提斯（Cervantes）等？然后放入Burroughs，Faulkner，Hemingway，Sylvia Plath等。该指标不起作用。

我将通过审核（并查找其过程中的偏差）来衡量这一点。

我将寻找一个证据证明交付过程涉及中央源代码控制，中央构建系统，以及确保在集成到已发布分支之前测试代码的过程。

我还将寻找证据来证明他们如何针对发布过程中出现的缺陷进行了修改。

如果他们无法通过此级别的审核，则不能期望他们提供一致的可靠版本。

如果他们通过了此审核，并且不断改进其流程，则其输出的一致性可能会随着时间的推移而改善。

如果这不能解决问题，那么他们很可能会遇到代码体系结构问题，这将导致扩展和测试其当前代码库成为问题，在这种情况下，没有好的选择。

如果您正在寻找完全自动化的测量方法，那么我建议这些人：Software Improvement Group

它本质上是可以从源代码中自动提取的各种度量的汇总（例如，单元测试覆盖率，函数大小，类纠缠，重复，LOC等）。然后将这些值转换为1-5星评级。

他们还有一本不错的书，描述了他们在实践中的所有指标，值得一读：“构建可维护的软件”。