指标解读

上一篇文章我们已经部署好了Sonar的产品和接入上报SonarQube控制台，这次我们来对SonarQube的全面解读，解读所有的指标，这能让我们更好的了解我们的项目工程代码的质量。

Bug 问题

• BUG定级
  A：表示代码无 Bug，最高级别
  B：代码有一个 次要 Bug，等级评估为 B
  C：代码有一个 重要 Bug，等级评估为 C
  D：代码有一个 严重 Bug，等级评估为 D
  E：代码有一个 阻断 Bug，等级评估为 E，最低级别

• Bug 的严重性等级
  Blocker（阻塞）
  定义：可能会导致系统崩溃，无法启动，或者引发致命错误。需要立刻修复。
  示例：空指针异常（NullPointerException）导致系统崩溃，严重的内存泄漏。
  Critical（严重）
  定义：可能导致应用程序产生逻辑错误、无法正确运行或者性能问题。需要尽快修复。
  示例：数组越界，除零错误，无法执行的死代码，导致逻辑混乱的错误。
  Major（主要）
  定义：不直接影响应用程序的正确性，但会影响可维护性，可能导致后续修改时出错。值得修复。
  示例：使用了过时的 API，冗余的代码块（比如多次调用相同的方法），不合适的算法或不推荐的编程实践。
  Minor（次要）
  定义：不影响应用程序的功能或稳定性，仅影响代码的可读性和维护性，优先级较低。
  示例：命名不规范、代码格式问题（如不一致的缩进或空格），重复的代码块。

• Bug 修复的优先级
  Blocker 和 Critical：这些是最需要优先修复的 Bug，通常会直接影响到系统的功能或者稳定性。如果遇到这些问题，应该立刻处理。
  Major：这些问题可能不会立即影响系统，但长时间存在会导致后期维护困难，增加技术债务，应该尽量解决。
  Minor：这些问题的影响较小，主要影响代码的整洁性和可维护性，可以在时间允许的情况下逐步修复。

我们进入Bug列表查看Bug的原因，点击一条列则进入详细的代码问题点，SonarQube会高亮显示出代码的问题处，鼠标移动过去能显示具体的问题原因，并能给出如何解决该问题的示例。

Vulnerabilities 漏洞

• 定义：漏洞是指代码中可能被恶意用户利用的安全缺陷。SonarQube 会扫描常见的安全问题，如 SQL 注入、XSS（跨站脚本攻击）等。
• 解读：
  没有漏洞：代码不含明显的安全问题。
  漏洞存在：可能会被黑客或攻击者利用，影响系统的安全性。
• 推荐：项目应力求 无漏洞，严重漏洞应立即修复。

漏洞和Bug类似的功能，我这里使用了不安全的加解密方法被检测出来，也给出了安全的加解密的使用方式。

Security Hotspots 安全热点

• 定义：安全热点是指存在潜在风险的代码，可能不会直接导致漏洞，但容易被错误的使用或误配置，成为安全问题的源头。
• 解读：
  无安全热点：表明代码在潜在的安全风险上管理良好。
  存在安全热点：需要仔细审查相关代码，并根据实际情况决定是否需要更改。
• 推荐：定期审查并解决安全热点，避免潜在的风险暴露。

一般对HTTP请求的方法进行强制指定该用GET还是POST的明确允许方式，避免在GET的方式明文给出参数被泄露数据的风险。

Smells 异味

• 定义：代码气味是指代码中的潜在问题或反模式，它们可能不会直接导致错误，但会使得代码可维护性下降。
• 解读：
  无气味或少量气味：表示代码质量较高。
  大量气味：表示代码需要重构。
• 推荐：尽量减少气味，确保代码结构简洁、可读。

一般是方法太复杂了，建议优化此类方法，避免历史债务积累后难维护的问题。

Coverage 覆盖率

• 定义：代码覆盖率是测试代码覆盖源代码的比例。它衡量了自动化测试的范围。
• 计算公式：
  plaintext
  复制代码
  Code Coverage = (测试执行的行数 / 总行数) * 100
• 解读：
  高覆盖率：意味着代码经过了广泛的单元测试，能够帮助捕捉错误和防止回归。
  低覆盖率：测试覆盖不充分，增加了生产环境中 bug 和回归的风险。
• 推荐：代码覆盖率应达到 80% 或以上。不过，覆盖率并不是唯一的质量标准，测试质量同样重要。

代码覆盖率需要整个团队对自测的要求，单元测试的编写是一个费时费力的工作，大部分的团队都不要求强制做这类的事情，就如code review一样，可能只做了一阵由于赶进度赶时间大家都没精力投入在这里了，慢慢荒废掉。
我们需要引入AI技术自动生成类单元测试代码，减轻我们的工作事项，让我们自测更轻松。

最后

说在最后，相信非常之多的团队对代码质量这块绝大部分都依赖测试团队的支持，从而对代码自身的质量检测较少的投入，所以我说Sonar的产品是程序员一般都不喜欢它的一部分原因。一部分我们害怕出问题，更甚者移交测试之前都没自测过，连启动都启动不了，移交过去也是浪费测试团队的时间。

在单元测试上我们也难有好的工具给我们提效的，写单元测试也是很痛苦的一件事。好在AI发展的还不错，我们能借助AI工具给我们的代码进行优化，生成各种代码和单元测试代码。

所以现在开始，让我们把质量按下重启键吧，从新出发。