代码检查规则运营需关注的10大指标
本文分享自华为云社区《代码检查规则运营一般会关注什么指标？》，作者： gentle_zhou。
代码检查服务的度量运营看板，除了先前提到的告警运营模块（其中的指标，可以参考这篇文章《代码检查告警运营一般会关注什么指标？》），必定还会存在的一个模块是规则运营。这个模块关注于对代码检查的规则进行分析、处理和汇报，对于团队项目管理者来说，可以监控和管理到规则的整体状况，具体可以参考我上一篇文章《代码静态检查为什么需要对规则去做运营？》。
今天我们再聊的细化一点，在看板内的规则运营模块里，用户一般会关注哪些指标呢？大致可以分为规则本身维度的数据：规则名称，规则版本，规则内容，相关语言，相关工具及类别，告警类别，适用范围；以及 规则关联维度的数据：规则相关联的维护责任人信息，规则相关联的被引用情况，规则相关联的规则集。
规则本身维度
规则名称
规则名称，可以让用户从字面上大致了解到规则的含义和作用，方便用户识别和管理规则。作为规则运营里最基本的几个指标之一，其可以支撑用户快速了解识别公司、产业线、部门下都有哪些规则，不同的部门都更偏向于使用哪些规则。
我们以华为云CodeArts Check代码检查服务为例，规则名称的设计就是要以清晰、简单为基准：
规则版本
规则随着演进，必定会有多种版本，包括各种大版本（可能是全年或则半年一个迭代）、小版本（不定期的小优化改进）。版本一般也是版本号的代替叫法，而版本号一般也会带有时间日期（代表其创建时间/修改时间/上线时间等），反映出规则的更新情况。
代码检查服务的运营看板上，在规则运营模块里，必定有对规则版本的记录。规则版本指标不仅可以帮助用户区分不同版本下的规则，也可以帮助管理者了解规则的演进过程，评估规则在不同版本底下对业务的影响，规则优化的演进历史以及规则的稳定性。
规则内容
如果说规则名称可以帮助用户大致了解规则的含义，那么规则内容就是为了让用户清晰明白的了解规则到底是什么，规则产生的背景，规则可以用在哪，规则的正确及错误示例，规则参考了什么规范等等。
规则内容可以说是帮助用户理解规则的一个非常重要的指标，协助用户掌握规则的检查方法和标准。因此一条规则是否具备了完整详尽的内容，且里面内容是否准确详实，就是运营看板用户所关注的。
以华为云CodeArts Check代码检查服务为例，概览里分为描述、正确实例、错误示例、修复建议、参见对规则内容进行细致的介绍：
相关语言
规则开发人员针对相关的编程语言，针对其语言特点，会设计开发适配的规则。尤其是一些主流语言，如Java，C，C++，Python等，一个成熟完善的代码检查服务里的规则都应该覆盖住。
在运营看板里，对规则根据语言进行分类，可以提高规则的可读性和可维护性，让用户根据语言筛选出贴合项目特性、符合开发人员语言习惯的规则，选择规则相配套的引擎工具，更加有针对性的对业务项目进行检测扫描。
相关工具及类别
规则若想要在代码检查服务里运作起来，除了规则本身之外，还需要配套的引擎工具来执行。规则由哪些引擎来执行，这些引擎属于自研的，开源的，还是商用的，都属于规则使用方所关心的。比如一个比较常见的场景是，一批规则本身是得到了部门和专家的认可，但在实际应用过程中发现产生的效果差别却很大；那这其中的一种可能就是这些规则配套的引擎差异所造成的，一些引擎效果好，将规则的效果执行到位，那么检查扫描的效果就出来了；但如果配套的引擎本身效率性能一般，那扫描的效果就有可能大打折扣。
我们还是以华为云CodeArts Check代码检查服务来举例，不同的规则会对应着不同的引擎工具，这些都会在规则详情界面的label里展示出来：
告警类别
就像我在《代码静态检查为什么需要对规则去做运营？》一文中所说的，规则类似于法律法条，那么违反的这条规则是属于民事类，交通类还是刑事类呢？这时候，就需要告警类别来展示了。
通常来说，告警类别可以分为三大类来展示：安全类，质量类，风格类（当然也可以把质量类和风格类结合在一起来展示）。如果公司质量部门对三大类的分法觉得粗颗粒度了些，也可以再继续细分。
以华为云CodeArts Check代码检查服务的分类来示例（分类栏里提到的“安全增强特性包”属于安全类的一个拓展分支，对一些安全问题场景提供更深度的扫描）：
适用范围
提到适用范围，那我们就得先额外简单介绍下代码检查工具的使用方式。除了常见的云端服务里，配合代码仓提供的门禁级扫描，配合流水线提供/手动触发的版本级扫描之外，研发人员在本地IDE中开发代码所需要的IDE插件扫描也是至关重要的。我们暂且将这三种使用方式称呼为版本级，门禁级，IDE插件级吧，那这三种方式也就可以说是服务的适用范围了。
对于规则来说，适用范围也是生效的。结合规则本身的特点，是否需要编译，配套的引擎扫描是否需要大量的计算资源，是否需要污点分析等等，来对规则的适用范围进行划分。一些占用计算资源少，不需要编译的规则就可以被选作IDE插件的扫描范围。在运营看板的规则运营模块里，针对适用范围对规则的分类就可以让用户了解到不同范围内都可以选哪些规则来应用。
规则关联维度
规则相关联的维护责任人信息
规则是会随着业务发展，行业内对漏洞感知的更新而不断更新优化的，因此需要有专门的维护部门和维护责任人来负责规则的上下线，修改，发布和管理。
在运营看板内展示规则相关联的维护责任人信息，大致上来说有以下2种原因：
- 一般来说规则是谁设计开发的，后续就应该由谁来维护；因此在看板内展示维护责任人信息，可以方便用户了解规则的来源和背景，提高规则的可信度和权威性。
- 方便用户在看板内发现一些规则相关问题或则建议时，能够快速联系到相关责任人，降低用户和开发者之间的沟通成本。
规则相关联的被引用情况
规则被开发出来，只要它合理且有效，一定会被公司内不同的产品线，部门，工程所采纳使用，理论上被引用的越多，越能代表规则的普适应，有效性和影响力。
在运营看板内展示规则相关联的被引用情况信息，大致上来说有以下3种原因：
- 帮助规则的使用者和潜在使用者了解规则的适用场景和使用对象，支撑它们选择合适的规则，提高代码检查的效果。
- 提供规则的维护责任人一个了解其开发规则适用范围的平台，可以和其内心预想效果做个对比；同时也可以通过和这些使用部门相关干系人的交流反馈，及时发现规则的问题和不足。
- 方便代码检查服务的管理人员和监督者了解规则的价值和影响力，对比和评估不同规则的差异。
规则相关联的规则集
代码检查服务的用户在使用规则的时候，并非直接选用规则去做扫描，而是会结合其业务特点，需要遵守的代码规范、安全标准或则说质量要求，选择一些规则合并成为一个集合去使用。这个集合我们一般称为规则集，可以方便用户去做增删查的管理。
在运营看板内展示规则都被那些规则集所使用，可以帮助用户了解：
- 规则的来源和依据，让规则的使用者明白为什么这个规则会出现在我们部门、工程中，来源于哪个规则集，被当前工程所引用是否合适。
- 规则的归属和分类，让规则的维护责任人了解规则会被哪些规则集所收集，这样的使用方式是否和初衷一致，是否可以根据这个场景对规则做补充和优化。
- 规则的分布和覆盖，支持代码检查服务的管理人员和监督者评估规则的价值和影响力，对比和评估规则在不同规则集内的效果和可信度。
延伸开来讲，公司业务量一大，工程数多了之后，必定会导致规则集数量也不可控的暴增。那么一味的展示规则被哪些规则集所采纳使用，也不是个很好的方式。我们可以选用一些典型的受到大家认可的规则集来评估，比如规则是否被公司层面的规则集所采纳；当一条规则的影响力和效果得到了整个公司层面的认可的时候，必定会被收录进公司级的规则集中。因此摒弃展示所有采用的规则集的方式，我们可以试着展示这条规则是否被公司层面的规则集所采纳，这样的效果可能更让用户接受，促进规则维护责任人改进的动力。
总结一下
通过关注如上这些指标信息，可以让相关人员获取规则相关的关键数据，帮助用户了解和评估规则的有效性、合理性、可维护性和适应性。用户也可以从中避免不必要的时间和资源浪费，帮助从运维的角度识别不可靠不一致的规则，避免不清晰和混乱，以达到提高规则的执行效果，当然最终目的也是为了保障用户的满意度。
