DevOps探索之旅（四）——代码静态分析

在流水线中拉取代码后，可不敢直接build，有诗曰：代码质量不确保，上线一堆bug跑；要想代码质量好，检查工作少不了；问题发现要趁早，未来返工成本高；懒得去填检查表？流水线里配扫描。于是小开在流水线里增加了Sonarqube对代码进行分析，按照教程一顿配置就可以用了，简单。

才怪。

刚开始使用Sonarqube的团队可能会面对这样的场景：代码规则这么多，那就用默认的sonarway吧；质量阈不知道咋设置，也默认吧。确实，对于初学者来说内置的sonarway是官方推荐的规则配置，但是扫描结果往往会出现很多“异味”，不同于bug或者漏洞会直接影响代码的功能和安全，“异味”的危害性没有那么高，只是影响可维护性而已。当前开发任务那么紧张，“异味”不影响需求上线，那就放在那里以后再说吧。于是随着代码的增加，“异味“也随之堆叠到可怕的数量，变成了代码“屎山”，没有人能弄懂，也没有人敢乱动，想解决也有心无力了。

 小开表示我们可不是这么没追求的团队，bug、漏洞和异味都要解决，但考虑到不同的团队和项目特性，除了使用默认的规则配置，要怎么选择适合自己的规则呢？

Sonarqube提供了内置的规则标签，可根据标签对规则进行初步的筛选。常见的标签如：

brain-overload（代码太复杂导致大脑超载）

bad-practice（虽然能实现功能但方式不好）

clumsy（本可简单却整麻烦了）

confusing（让人看不懂）

convention（编码规范）

pitfall（当前没问题，但可能给后来人挖坑）

……

同时，可结合相关的标准进一步筛选代码规则。Sonarqube内置的标准包括OWASP、CERT、CWE等，OWASP和CERT与安全有关，将在后续的主题中介绍，CWE(Common Weakness Enumeration)是一个常见软硬件弱点类型的清单，不仅包括安全漏洞，也包括其它方面的质量弱点，在其官网提供了查询功能，通过相应的关键字能够查询到对应的弱点描述及编号，再用其CWE编号到Sonarqube中即可搜索出对应的规则。

CWE查询页面

 然而上面这些都不够系统，小开希望有一个成体系的代码规则，团队可以根据不同的需求进行裁剪。《ISO/IEC 5055:2021 -自动化源代码质量度量》这一标准则比较系统性地给出了代码质量的若干特性，以及每个方面特性对应的CWE有哪些。ISO/IEC 5055:2021将代码质量分为可维护性、性能效率、可靠性、安全性四大特性，每个特性下有若干质量度量元素，并描述了每个质量度量元素的CWE编号、描述符、弱点描述、和其它CWE的继承关系等。

ISO/IEC 5055:2021 代码质量度量框架

性能效率的质量度量元素部分示例标题

 

基于该标准提供的质量特性分类和质量度量元素，结合Sonarqube的标签，团队就可以按照自己的需求进行裁剪，形成所需的代码规则库。在进行代码规则选择时，一般可能会考虑的因素有：

<开发语言和框架>

不同的编程语言有不同的代码规则，除了选择对应的语言，也可以按使用的框架和技术如spring、Hibernate等进行规则搜索。

<软件质量需求>

包括性能、安全性、可用性等产品级质量需求，以及代码的可读性、复杂度、覆盖率等内部质量目标，可通过相应的标签、标准或CWE编号筛选出对应的规则。

<团队水平和经验>

选择代码规则时还需要考虑团队成员的技能水平，规则过于严格可能会影响开发效率和开发人员的积极性，规则过于松散又会影响代码的质量和可读性。因此，需要在选择代码规则时做出平衡。

<编码风格和规范>

代码风格的一致性对于项目的可读性和可维护性非常重要。可以选择合适的代码规则，也可以根据组织已有的编码规范来开发代码规则，或导入第三方的代码规则库。

既然是自己定的规则，那扫描出来的代码异味可就不再坐视不理了，应按照规则中给出的不符合代码和符合代码的示例，将问题逐个修复解决，以减少遗留的技术债务，满足质量阈的要求。而质量阈的设置，除了和筛选代码规则时相同的考虑因素外，也需要结合组织和团队的效能度量目标，参考相关的标准确定具体的指标阈值，这部分将在后续的效能相关主题中进行介绍。

总之，要想代码质量好，自动分析是个宝；规则太多可咋搞？标签标准里面找；需求团队style，这些最好考虑到；bug异味全干掉，PM跪下叫大佬。