代码检查规则背景及总体介绍

中秋小长假结束，放松过后的你准备好新一轮的学习了吗？端坐小板凳开始study吧！

今天为大家带来的课程是《代码检查规则背景及总体介绍》，将从代码检查的意义、代码检查场景及工具、代码检查规则分级三个方面来解读代码检查规则。

提高代码可读性，统一规范，方便他人维护，长远来看符合公司内部开源战略。

帮助发现代码缺陷，弥补人工代码评审的疏漏，节省代码评审的时间与成本。

有助于提前发现问题，节约时间成本，降低缺陷修复成本。

促进公司编码规范的落地，在规范制定后借助工具进行准入检查。

提升编码规范的可运营性，针对反馈较多的不合理规范进行调整更新。

首先是本地研发环节，借助客户端工具，在push发起评审之前进行检查。

若本地代码扫描没有出现问题，就进入第二个环节：代码准入环节，即Code Review，这一环节进行增量检查，属于公司强制要求。

第三个环节：持续集成环节，当代码合入到代码库之后，进行全量检查，业务线根据自身需求来配置。

代码检查的产品，客户端、SCM(icode)、CI(Agile)之间具有交互性，共同构成整个代码检查环节。

在覆盖语言方面，代码检查目前已经覆盖了包括C++，Java/android, PHP, Python, Go, JS, OC, Kotlin在内的几乎所有主流语言。

在检查维度方面，代码检查包括编码规范代码缺陷，开源框架引用安全检查，可维护性(MI)。

编码规范：只扫描变更文件，检查代码变更行是否符合规范，速度较快。

缺陷检查：需考虑文件依赖、函数调用关系、代码上下文等，相对耗时。

Code Review阶段，所有维度扫描出的问题可以分为以下3个等级：

（1）Error：属于需要强制解决的类型，影响代码合入，应视具体情况不同采取修复、临时豁免、标记误报等措施及时处理；

（2）Warning：非强制解决类型，不影响代码含入，很可能存在风险，应尽量修复；

（3）Advice：非强制解决类型，级别相对较低，不影响代码含入，可以选择性修复。