软件开发开始以来，乱象丛生，人们总是问“做对了吗？”我们得到混合的答案：

最老的一个： 嗯，它编译
似乎有效
普遍的最爱： 用户没有抱怨（直到用户开始抱怨或者我们必须添加新功能，然后我们才能弄清楚我们做得有多好）
最新回答： 自动化测试用例（How do you know if you have enough tests if you have enough tests, and the things of the things can't covered by tests）

我们如何评估 代码的质量 和编写代码的开发人员？评估工厂工人（以可接受的质量生产的产品）、律师（赢得的案件）等很容易。

那么，如果我们可以 衡量软件质量， 就可以回答这个问题。软件质量可以很容易地通过抽象来定义，从不同的角度检查它，并沿着不同的维度对它进行评级。

让我们来做个测试，看看我们是否能读懂这个：

我意识到我没有意识到我是 rdgnieg。 hmuan mnid 的 phaonmneal pweor。它不是世界上的读者所关心的，而是最重要的，它应该在正确的地方。初始值可能是一个 taotl msess，您可以在没有 porbelm 的情况下对其进行扫描。 Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the word as a wlohe.

前面的文本没有一个拼写正确的单词，但证明是可读的。从产品的角度来看，有人可能会支持，尽管文本有缺陷，但它起到了作用，因为它设法保持可理解性。但这有恶化最终阅读体验的副作用，需要额外的努力来重建单词和短语。读者不自觉地用心思去改编和破译这些乱七八糟的词。另一方面，被指派改进或添加文本的编辑将不得不应对这种拖延整个过程的非标准写作实践。

切换软件产品源代码的损坏文本。读者现在是产品的最终用户，编辑是开发人员。他们都以不同的方式体验产品质量，每个人都从自己的角度出发。从功能角度看最终用户，从结构角度看开发人员。

软件质量度量 是对加权属性值求和的量化过程，这些属性值部分描述了特定的软件特性。对于每个特征，定义了一组这样的可测量属性。

现在的问题是，什么是 软件特性 ？好吧，它可能是：

编码是否遵循特定约定
是否遵循了众所周知/既定的良好做法并避免了众所周知/既定的不良做法
是否存在任何潜在的错误和性能问题、安全漏洞
有没有重复代码
代码逻辑是否很复杂
公共API是否有完善的文档和注释
代码是否有单元测试
代码是否遵循良好的设计和架构原则

我们如何定义相应的属性呢？

属性	加权值
拦截器	5个
批判的	4个
主要的	3个
次要的	2个
信息	1个

在定义了软件特征之后，我们想到的下一个问题是我们如何自动执行它？答案在于静态代码分析。

静态代码分析

静态代码分析是用于分析源代码以自动发现潜在错误或不良编码实践的算法和技术的集合。这个想法在本质上类似于编译器警告（这对于查找编码错误很有用），但是将这个想法更进一步，发现传统上使用运行时调试技术（如测试）发现的错误。

静态代码分析，通常也称为“白盒”测试，着眼于非运行时环境中的应用程序。这是覆盖整个代码库并识别所有易受攻击模式的唯一经过验证的方法。静态代码分析也被认为是一种自动化代码审查过程的方法。

静态代码分析软件解决的任务可以分为3类：

检测程序中的错误
关于代码格式的建议。一些静态分析器允许您检查源代码是否符合您公司接受的代码格式标准
指标计算。软件指标是一种度量，可让您获得软件或其规范的某些属性的数值

有许多可用的静态分析工具。然而，Checkstyle、PMD 和 FindBugs 是众所周知的，并在大多数项目中使用

格纹

Checkstyle 是一个开源工具，可以帮助执行编码标准和最佳实践，特别关注编码约定。 Checkstyle 确实涵盖了一些静态代码分析功能（与 PMD 和 Findbugs 的方式大致相同），但是我们将主要专注于使用 Checkstyle 检测和执行编码约定。

主要焦点：公约

PMD

PMD 是一种静态代码分析工具，能够自动检测各种潜在缺陷和不安全或未优化的代码（不良做法）。 Checkstyle 等其他工具可以验证编码约定和标准是否得到遵守，而 PMD 更侧重于先发制人的缺陷检测（确保遵循良好实践）。它带有丰富且高度可配置的规则集，您可以轻松配置给定项目应使用哪些特定规则。

不良实践类型由众所周知的行为组成，随着时间的推移，这些行为几乎会系统地导致困难。以下是一些不良做法的示例：

捕获异常而不做任何事情
有死代码
太多复杂的方法
直接使用实现而不是接口
在不使用 not equals(Object object) 方法的情况下实现 hashcode() 方法
布尔同步（可能导致死锁）
可以通过返回对可变对象的引用来公开内部表示

主要焦点：不良做法

查找漏洞

FindBugs 是另一个 Java 静态分析工具，在某些方面类似于 Checkstyle 和 PMD，但侧重点完全不同。 FindBugs 不关心格式化或编码标准，只对最佳实践略感兴趣：事实上，它专注于检测潜在的错误和性能问题。它在发现这些问题方面做得非常好，并且可以检测出许多类型的常见的、难以发现的错误。事实上，FindBugs 能够以相对较高的精度检测与 PMD 或 Checkstyle 完全不同的一组问题。因此，它可以成为静态分析工具箱的有用补充。

主要焦点：潜在的错误

惠普强化

根据 HP Fortify 网站——

“HP Fortify Static Code Analyzer 有助于验证您的软件是否值得信赖、降低成本、提高生产力并实施安全编码最佳实践……”

主要特征

通过识别构成最大威胁的漏洞来降低业务风险
通过可重复的过程快速识别并消除可利用的漏洞
通过在 SDLC 的早期识别漏洞来降低开发成本
在开发人员工作时对他们进行安全编码实践教育
将开发和安全团队聚集在一起以查找和修复安全问题

主要焦点：安全漏洞

声纳管

SonarQube 收集和分析源代码，测量质量并为您的项目提供报告。它结合了静态和动态分析工具，可以随着时间的推移连续测量质量。影响我们代码库的一切，从次要的样式细节到关键的设计错误，都由 SonarQube 检查和评估，从而使开发人员能够访问和跟踪代码分析数据，从样式错误、潜在错误和代码缺陷到设计低效、代码重复，缺乏测试覆盖率，以及过度的复杂性。 Sonar 平台从不同方面分析源代码，从而逐层深入到您的代码，从模块级别向下移动到类级别。在每个级别，SonarQube 都会生成指标值和统计数据，揭示源中需要检查或改进的问题区域。

为什么选择 SonarQube

您可能想知道 SonarQube 是否使用现有的、经过验证的工具，那么为什么要使用它呢？您可以将这些工具配置为 CI 服务器中的插件，然后我们就完成了。不一定，还有很多注意事项。

截至目前，CI 工具还没有可以让所有这些一起玩的插件
截至目前，CI 工具没有像 SonarQube 那样提供良好的向下钻取功能的 pugins
CI 插件不谈整体合规价值
CI 插件不提供管理视角
截至目前，还没有针对设计/架构问题的 CI 插件
它不提供总体项目质量的仪表板

特征：

SonarQube 不只是告诉你哪里出了问题。它还提供质量管理工具，积极帮助您纠正错误
SonarQube 的商业竞争对手似乎将他们对质量的定义主要集中在错误和复杂性上，而 SonarQube 的产品则涵盖了其创建者所说的质量七轴
SonarQube 不仅解决了错误，还解决了编码规则、测试覆盖率、重复、API 文档、复杂性和架构，在仪表板中提供所有这些详细信息
它为您提供了当前代码质量的即时快照，以及滞后（已经出错）和领先（未来可能出错）质量指标的趋势
它为您提供指标以帮助您做出正确的决定。在几乎每个行业中，认真的领导者都会跟踪指标。无论是制造缺陷和浪费、销售和收入，还是棒球命中率和打点，都有一些指标可以告诉您您的表现：整体表现是否良好，或者您是在变好还是变差。

让 SonarQube 真正脱颖而出的是，它不仅提供有关您的代码的指标和统计数据，而且将这些非描述性价值转化为真实的业务价值，例如风险和技术债务。 SonarQube 不仅针对核心开发人员和程序员，而且由于它提供的管理方面，还针对项目经理甚至更高的管理级别。 SonarQube 增强的报告功能和从不同角度处理源代码的多个视图进一步加强了这一概念。

从管理的角度来看，对历史数据的透明和持续访问使管理人员能够提出正确的问题。

注意： SonarQube 绝不与上述任何静态分析工具竞争，而是对这些工具 进行补充 并与这些工具一起工作得很好。事实上，如果这些静态分析工具（Checkstyle、PMD 和 FindBugs）不存在，它就会停止工作。此外，我们可以使用此插件将 Fortify 与 SonarQube 集成。

参考