DevOps之静态代码扫描

Posted 2021-04-16 基哥杂记

技术债同财务债一样，是有利息的，还债的时间拖的越长，就需要支付更多的利息。很多临时性的代码、不合理的架构最终都会造成严重的后果。一个小的功能优化，可能会引发大面积的代码修改，大大提高了开发成本和测试成本，还很容易引入新的问题。历史代码都不敢修改和维护，最终代码越来越臃肿，无效代码越来越多。

开发人员七宗罪

《Sonar code quality testing essential》一书中从七个维度定义了代码的这种内在质量，Sonar开发团队上纲上线的戏称为开发人员七宗罪：

• 编码规范：是否遵守了编码规范，遵循了最佳实践。
  

• 潜在的BUG：可能在最坏情况下出现问题的代码，以及存在安全漏洞的代码。

• 文档和注释：过少（缺少必要信息）、过多（没有信息量）、过时的文档或注释。

• 重复代码：违反了Don’t Repeat Yourself原则。

• 复杂度：代码结构太复杂（如圈复杂度高），难以理解、测试和维护。

• 测试覆盖率：编写单元测试，特别是针对复杂代码的测试覆盖是否足够。

• 设计与架构：是否高内聚、低耦合，依赖最少。

基于Sonar的代码质量检查

1、Sonar质量管理平台

与当今众多的代码质量管理工具相比，Sonar的优势主要体现为：它是一个开源的代码质量管理系统，支持 25+ 种语言，可以与Jenkins、Eclipse 和 JIRA 等其他外部工具集成，从而实现了对代码的质量的全面自动化分析和管理。

Sonar 为代码的质量管理提供了一个平台，对传统的代码静态检测如 PMD、FindBugs 等工具进行整合，可以说是目前最强大的代码质量管理开源工具之一。

2、代码规范的定义

在应用Sonar辅助实施DevOps，帮助开发改进代码质量的实践过程中，我们发现会碰到很多的问题，其中最大的问题是，由于之前累积的技术债务比较庞大，缺乏代码质量规范，代码质量低下，导致应用Sonar默认规则进行代码扫描时，扫描出来的违反代码规则的代码量非常大，一下子给开发人员巨大的压力，开发下意识会拒绝修改这么大量的问题。

所以必须对代码扫描规则进行筛选、定制，前期尽量挑选适量的、高级别的规则进行扫描应用，等开发习惯后再分阶段逐步应用更多的规则。Java建议加入阿里巴巴的p3c开发规范。详见文章：

下面介绍常用的筛选策略：

1）针对不同系统进行评审、筛选、定制扫描规则集

企业内不同的系统（项目）的重要程度是有差异的，例如分为核心、重要、一般3种级别的系统，对不同系统定义的代码扫描规则集不同，例如：越重要的系统，规则范围越大（挑选的规则数量越多）、规则的严重级别设定越高。

2）针对不同系统的特点选取重点关注的规则类型

不同类型的系统（项目）的特点不一样，对代码质量的要求侧重点也会有差异，例如，有些系统侧重性能和执行效率，有些系统侧重可移植性。代码规则大致可分为以下几类：可维护性（Maintainability）、性能（Efficiency）、可移植性（Portability）、可用性（Usability）、可靠性（Reliability）。

3）每个规则有默认严重级别，需要根据项目情况调整重要级别

例如，在Sonar中展示的代码规则违反分类数量统计，分为5个级别：Blocker、Critical、Major、Minor、Info

可通过Sonar的配置管理界面对具体某个规则的严重程度（Severity）进行调整设置。

通过一系列的筛选和调整后，Sonar的规则会适当减少，例如，下面是挑选了Sonar中专门由Findbugs进行扫描的规则，并且仅挑选严重级别为Blocker、Critical的规则，代码扫描规则的数量由原来的500多个降到了200多个。

有了定制化的代码规则集后，我们还可以结合研发流程做质量门（质量标准），例如，下面是某企业对代码合规等代码质量标准的指标定义：

小结

在DevOps推进过程中，结合持续集成的代码检查环节，基于Sonar平台实现代码自动检查，通过筛选规则、小范围逐步引入，通过工具及质量门禁，就像安检一样从多个方面来检查每个研发同学提交的代码是否符合要求，是否达到放行标准，提前消除技术债务。