智慧城市市场规模将达8207亿美元

统计工具

sloccount、sourcemointor 这两个工具可以用于统计代码数量，包括行数、文件数、注释等。除了在项目中扫描 bug 之外，配置代码统计工具可以对项目有一个整体的认知。其他的扫描工具还很多，例如 coverity、codemars、binscope、synk、appscan、retire.js 等工具，不再一一列举。

最佳搭配

这几款工具之间的功能有所重叠，在实际工作中，我们可以根据上面推荐的关注的点，重点清除这些问题。这些扫描工具全部用上除了会带来团队压力和维护成本之外，代码质量不会随着引入的插件增多。除开有质量团队的大厂提供这些扫描平台外，敏捷团队往往不会太大，团队持续关注一个精简的扫描组合更好。

Java 后端：

• checkstyle Java 代码风格守护，Java 项目至少应该配置一个默认的 checkstyle 规则。至少让项目干净，没有无用、重复的代码，以及超大的类和方法。建议做到每次提交代码前检查。
• findbugs 常见不规范的代码检查，一些空指针、equals 检查非常有用，而且 IDE 的插件也很好用。

前端：

• eslint 守护 JavaScript 代码风格，eslint 搭配一个 .editorconfig ，可以方便的让编辑器保持同 eslint 一致的代码风格。
• npm audit 项目中第三方包的威胁扫描，npm 自带无需额外安装，npm 6 以后自运行，需要关注并修复报出的安全问题。

安全：

• fortify 扫描代码中的漏洞，用它检查出来的大部分安全问题都是注入攻击、XSS 等攻击，这些问题明显可以在开发过程中避免。可以作为 Jenkins 插件配置，和单元测试作为同一阶段运行。
• OWASP 插件 用来扫描第三方依赖漏洞，因为项目中的依赖不会像源代码一样频繁变化，推荐使用 Jekins 插件，定期执行即可。

为什么不用 SonarQube 呢，SonarQube 是一个非常优秀的代码质量开放平台，需要单独的配置安装，需要花费额外的时间维护，对于小团队来说成本较高，如果有专门的质量团队可以考虑维护一套。

常用代码质量指标参考

• 编译告警数，大部分程序员基本上忽略 warning，但是编译器出现了告警是一种不好的体现，意味着软件可能工作，但是存在不好的实践，而这种不确定性，会带来不确定的 bug 最终让人一头雾水。编译过程中的告警，尽量消除掉，编译告警的值推荐消除到 0。
• 平均函数代码行数，过大的函数会导致阅读困难，而且往往过大的函数职责不够单一，一般将一个方法代码行数控制到 30 - 50 行。
• 平均文件代码行，和平均函数代码行一样，过长的文件一样难以维护，一般一个文件10多个方法，因此文件的代码行数一般控制到 300 - 500 行。
• 冗余代码，有时候我们代码中可能存在未使用的方法、变量等代码，这让维护者一头雾水，通常需要清零。
• 总文件重复率，出现重复文件的次数。除了编写单元测试的情况下，业务代码不应该出现重复代码，推荐值为 0。
• 总代码重复度，代码的重复度检查，限于扫描工具的识别模式，需要有一定的容忍度，推荐值在 5% - 10%
• 平均函数圈复杂度，圈复杂度用来衡量一个模块判定结构的复杂程度。如果一个方法内部有大量的 if 语句嵌套，意味着这个方法的实现质量低下，且程序复杂度高不利于维护，推荐值小于 5%。
• 安全告警，如果配置了安全扫描工具，例如 Fortify，安全威胁应该被清零。
• 代码缺陷，如果配置了缺陷扫描工具，例如 Findbus，需要清零。

（编辑：周口站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!