如何产出规范、安全、高质量的代码？
极客时间编辑部
讲述：丁婵大小：9.31M时长：06:47
你好，欢迎收听极客视点。
对于一个软件开发团队，可以通过哪些代码质量指标和扫描方法让团队产出规范、安全、高质量的代码？公众号“ThoughtWorks 洞见”的一篇文章总结了其中一些实践和工具，极客视点摘录了“代码质量扫描工具”和“代码质量指标”这两部分的内容分享给你，希望对你有所帮助。
代码质量扫描工具
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，需要清零。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
Alan He由于性能问题，TypeScript 也采用了 ESLint 作为 TSlint 替代的检查工具。 这个观点从哪里得出的，核心原因是整合JS社区资源，tslint没有必要另起炉灶
丫头感觉更多是偏向后端...前端想要规范、安全、高质量的代码，可以怎么操作？
天天向上如何降低圈复杂度，有没有好的一些实践方法
收起评论