你好，欢迎收听极客视点。

对于一个软件开发团队，可以通过哪些代码质量指标和扫描方法让团队产出规范、安全、高质量的代码？一篇文章总结了其中一些实践和工具，极客视点摘录了“代码质量扫描工具”和“代码质量指标”这两部分的内容分享给你，希望对你有所帮助。

代码质量扫描工具

1. Checkstyle

这是常用于 Java 项目的扫描工具，检查源代码是否与代码规范相符，检查项目主要包括：Javadoc 注释、imports、过长的类和方法、空格、重复文件、圈复杂度等，默认使用 sun 的代码规则，也可以配置自定义的代码规则，例如阿里就发布了相应的检查规则。

2. FindBugs

通过 Bug Patterns 的概念，寻找代码中可能出现的 Bug，检查项目主要包括：不良编程习惯导致的问题、性能问题、安全问题、线程问题等。例如，应使用 equals 判断相等，而不是 “ =” 操作符、流需要关闭、线程资源需要释放等问题。FindBugs 的模式库对编程经验也有较好的提升作用，还可以导入和编写自己的 Bug Patterns 完善检查机制。

3. Simian

这是一个用于检查重复和相似代码的工具，它的重复检查类似于论文查重，会提示一定的相似度。可以单独运行，也可以作为 Checkstyle 插件来使用，相对来来说比较小众。

4. PMD

这是一款跨语言的通用静态扫描工具，具备一部分 Checkstyle、FindBugs 的功能，不再赘述。

5. ESlint/TSlint

前端界的 Checkstyle , TSlint 设计用来做 TypeScript 类型检查，ESlint 作为代码风格检查工具。不过现在 ESlint 也提供了TypeScript 类型检查功能，基本上 ESlint 能整合这两个功能。由于性能问题，TypeScript 也采用了 ESLint 作为 TSlint替代的检查工具。

6. SonarQube

SonarQube 是一款用于代码质量管理的开源工具，它主要用于管理源代码的质量。SonarQube 和上面的工具不太一样，SonarQube 设计目的是提供一个平台，通过插件的方式提供对各个语言进行支持，也可以和 Checkstyle、PMD、Simian 等工具进行集成。SonarQube 一般需要单独部署成一个服务，提供数据库，可以记录扫描结果等信息。

7. npm audit

npm audit 是 npm 6 之后的版本自带的一个前端安全扫描工具，可以扫描 npm 依赖中的潜在的漏洞威胁。这些引入的漏洞可能威胁用户开发的机，另外也可能被带入 bundle 文件发布到线上，带来安全问题。目前 npm audit 会在 npm install 完成后自动执行，需要留意安全威胁报告。

8. Fortify SCA

Fortify SCA(Source Code Analyzer) 是一款非常优秀的代码安全扫描工具，用于分析代码中潜在的安全问题。通过调用语言的编译器或者解释器把代码（Java、C、C++等源代码）转换成一种中间媒体文件 NST（Normal Syntax Trcc），然后通过模式匹配相关的方式抓取存在于漏洞库中的漏洞。例如，上传的文件没有做检查等 XSS 攻击。

9. OWASP Dependency-Track

开放式 Web 应用程序安全项目（OWASP）是一个非营利组织，提供了很多安全标准、数据库、社区和培训。其中一个工具就是 OWASP Dependency-Track，可以对第三方依赖包中的知名漏洞进行检查，扫描结果受到漏洞数据库的更新影响。

10. Archunit 架构规范检查

前面的检查是代码层面，archunit 可以用于代码架构检查，可以定义规则检查每个包中的实现是否符合规范。例如，controller 包中的类不能实现 service 的接口，repository 下的类必须实现 Repository 接口。通过 Archunit 可以减少 Code Review 的工作量，避免项目的结构被破坏。

常用代码质量指标参考

1. 编译告警数。大部分程序员基本上忽略 warning，但是编译器出现告警是一种不好的体现，意味着软件可能工作，但是存在不好的实践。而这种不确定性，会带来不确定的 Bug，最终让人一头雾水。编译过程中的告警，尽量消除掉，编译告警的值推荐消除到 0。

2. 平均函数代码行数。过大的函数会导致阅读困难，而且往往过大的函数职责不够单一，一般将一个方法代码行数控制到 30 - 50 行。

3. 平均文件代码行。和平均函数代码行一样，过长的文件一样难以维护，一般一个文件10多个方法，因此文件的代码行数一般控制到 300 - 500 行。

4. 冗余代码。有时候我们代码中可能存在未使用的方法、变量等代码，这让维护者一头雾水，通常需要清零。

5. 总文件重复率，即出现重复文件的次数。除了编写单元测试的情况下，业务代码不应该出现重复代码，推荐值为 0。

6. 总代码重复度。代码的重复度检查，限于扫描工具的识别模式，需要有一定的容忍度，推荐值在 5% - 10%

7. 平均函数圈复杂度。圈复杂度用来衡量一个模块判定结构的复杂程度。如果一个方法内部有大量的 if 语句嵌套，意味着这个方法的实现质量低下，且程序复杂度高不利于维护，推荐值小于 5%。

8. 安全告警。如果配置了安全扫描工具，例如 Fortify，安全威胁应该被清零。

9. 代码缺陷。如果配置了缺陷扫描工具，例如 Findbugs，需要清零。

以上就是今天的内容，希望对你有所帮助。