代码扫描和质量门禁的度量

质量门禁在各个部门的前期试点之下，准备在业务系统条线广泛实施了。门禁的顺利实施肯定离不开各个部门的大力配合，为了能让各部门在这个过程中体现出各自的成绩，需要准备几个度量项目，让大家能把故事讲好。

• 已经有的指标，金银铜奖牌榜

在试点期间，将质量门禁设置成了金银铜三档，代表不同的质量要求，如单元测试覆盖率等。这个榜单对于促进质量门禁的实施还是起到了一定的效果，特别是在和高层的沟通时，由于易于理解，可以说是讲好了质量门禁的故事。

• 拟考虑设置的指标

除了这个榜单之外，周末又梳理了一下，感觉可以从以下指标入手

1- Issue解决数量榜单

代码扫描出来的Issue并不能提升质量，而是Issue在被扫描出来之后被团队解决处理掉了才会有效果。因此，在质量门禁圈住了增量Issue之后，通过Issue的处理量来表征团队在处理存量上的投入程度。

2-单测用例数量、趋势和用例修复条次

有效执行的单元测试的数量，表示了团队在质量内建方面有持续的投入。另外一个考虑角度是用例修复条次。

3-扫描次数

扫描次数越多，说明平台发挥作用越频繁。也可以从侧面反应开发人员向主干合并代码的频次更高。

那么，这些指标真的有效吗 ?

• 希望团队达到什么样的质量内建目标？

度量是为了改进目标服务的，通过度量来牵引团队做期望的事情，最终达到期望的改进目标。

那么，质量内建的目标是什么呢？

1、新增代码有单元测试覆盖，以证明其符合需求预期，并且不会引入已知的问题。

2、开发人员在将代码合并进团队的代码库时，应该已经达到目标1的要求，因此不会导致质量的劣化和技术债的新增。

思考下来，感觉要做的其实是以下的事情

1、代码提交环节一定做到质量门禁带电。例如使用Gitlab/Github的话，一定是要求使用MR/PR来在团队代码库上提交代码，而不允许使用push。先污染再治理，最后只能是债多不愁，下个版本再说。

2、平台要支持或者鼓励开发人员提前进行扫描。在本地构建或者私有代码库上提交时，能否触发扫描来提前发现问题。这样，在后面向团队代码库或者主干提交代码时，就可以一条过了。

因此，可能只要关注以下的一个指标就够了

质量门禁的通过率= 质量门禁的通过次数/总扫描次数

前提是：质量门禁带电