转载

代码度量平台

背景

公司业务飞速发展，技术团队不断扩张，面对这样的局势，技术团队引入了很多高P的人才，他们有着不同的大公司背景，在引导团队不断向前的同时，也面临着技术上的挑战。

大部分技术人员来自不同的公司，有着不同的技术背景，也深受着以往公司的技术文化影响，大家的编码风格、编码规范都带着过去的影子。
甚至有些同学不知道做单测意义，觉得测试同学有接口自动化就足够，
团队内部同一个项目中也会出现不同的风格，开发主管也没有那么多精力去review开发的每行代码。

这个时候就需要通过一些技术手段来解决代码规范检查的问题，协助开发完成单测、安全检查。通过一些自动化的方式来度量开发的代码质量，并能够及时发现问题，保证开发提交的代码都是高可用，高质量的。同时可以为团队的管理人员提供一些有效的量化结果，指导做一些流程和技术上的优化。通过提升研发代码质量，增强研发对于提交测试代码的信心。同时保证代码的高质量，高可用性，高可读性，随时保证代码分支的代码纯净，并能够很好的支持CI/CD。为达到上述目的，我们开发了代码度量平台。

目标

平台目标:

代码优化的依据
衡量研发质量
做到质量闭环

具体实现分以下四个方面来逐步实现

规范化: 1. 编码规范 2.二方包发布规范 3.三方包引入规范

自动化: 1. 自动化分析 2. 自动化统计 3. 自动化生成分析报告

定制化: 1. 结合个业务线特点制定公司/业务线/敏捷组/项目组四个级别的扫描规则

流程化: 1. 绑定研发流程 2. 前置扫描过程

代码度量平台应用列表展示

应用新增页面

质量检查详情

代码度量平台设计

平台设计

引入使用 SQALE代码质量评估模型的SonarQube进行代码静态扫描，辅以 Cobra 的进行代码审计，Synk 进行三方包漏洞扫描，形成一套完整的代码度量工具链。

其中编码规约方面，我们引用以阿里巴巴Java开发手册为基准的P3C规则，结合业界权威 FindBugs，PMD 等扫描规则集，形成了酷家乐专属定制的Java编码规范: KuJava规则集。

技术架构

统一度量

如何以客观、准确、可复制和自动化的方式来统一度量代码质量？

具体指标(违反规则数? 规则严重等级？)还是技术债 (可读性, 扩展性, 可维护性, 复杂度)？

我们以SQALE分析模型为参照标准，从可测性，可读性，可理解性，容变性等代码可维护性维度的质量属性来衡量代码质量。结合公司实际，总结出了一个科学的度量模型:

质量总分 = 单测通过率得分 + 单测行覆盖率得分 + 重复度得分 + 复杂度质量分 + 坏味道质量分 + BUG质量分 + 漏洞质量分

•单测通过率得分 = 单测通过率 * 权重，权重 5分

•单测行覆盖率得分 = 单测行覆盖率 * 权重，权重 5分

•重复度得分 = 10 - 重复度，权重 5分（<=5% , 满分, >=10% , 0分，每增加 1% 扣 20%)）

•复杂度质量分 = 5 * (1 - 千行复杂度/千行复杂度质量红线 ) ，权重 5分（>质量红线，0分）

•坏味道质量分 =7 * (1 - 千行坏味道阻断数/千行坏味道阻断数质量红线 ) + 2 * (1 - 千行坏味道严重数/千行坏味道严重数质量红线 ) + 1 * (1 - 千行坏味道主要数/千行坏味道主要数质量红线 ) ，权重 10分（>质量红线，0分）

•BUG质量分 =20 * (1 - 千行BUG阻断数/千行BUG阻断数质量红线 ) + 7 * (1 - 千行BUG严重数/千行BUG严重数质量红线 ) + 3 * (1 - 千行BUG主要数/千行BUG主要数质量红线 ) ，权重 30分（>质量红线，0分)

•漏洞质量分 =28 * (1 - 千行漏洞阻断数/千行漏洞阻断数质量红线 ) + 8 * (1 - 千行漏洞严重数/千行漏洞严重数质量红线 ) + 4 * (1 - 千行漏洞主要数/千行漏洞主要数质量红线 ) ，权重 40分（>质量红线，0分）

度量模型不仅可以多维度，科学地度量一个项目代码的健康情况，更可以结合公司在不同阶段的度量改进重点，通过调整权重快速改变质量分的分值，已达到代码质量持续改进的目标。

平台运营

数据驱动

有代码度量，我们如何驱动代码质量提升？数据驱动+流程卡点是一个很好的方式

代码质量趋势图，以业务组维度，度量研发周期内的代码质量趋势。

单测Top红黑榜排名，通过代码质量通晒的方式来督促研发质量提升

流程卡点

结合发布系统，进行部署节点的质量卡点

各业务线可自定义应用质量红线，形成业务线质量公约。

2. 应用每次CD进行质量检测，显示质量分析报告，质量报告包含(接口测试，代码扫描，二方包检查，sql预检)四部分内容，全部指标达标才可发布。

3. 超过阈值的应用质量将显示不达标状态，质量检测不达标的应用限制流转，如需紧急发布，需申请上级Owner审批。

正常流转

质量运营

质量运营策略需要结合代码质量的现状来指定，我们结合公司的实际情况，指定了不同阶段的运营策略。

阶段1: 代码违规清理

代码度量初始阶段，我们的工作重点是解决代码中可能导致Bug的隐藏问题，规范代码编写。这个阶段我们度量重点指标为阻塞/致命/严重级别的 Bug 和 Vulnerability 个数，映射到质量分中的数据为 BUG质量分，漏洞质量分，所以这个阶段的这两个部分的权重分别为30，40，即若出现 2 个以上阻塞/致命/严重的问题，该仓库的质量分将达不到质量红线 65.

阶段2: 重复代码治理

再经历阶段1 的问题清扫之后，代码中的明显潜在问题都已经消除，我们转向代码治理方向。

每个程序员的极致追求，都是写出一份优雅的代码，那什么是好的代码？

这阶段的重点是将代码从"ctrl+c"到"ctrl+v"解放出来，从代码能工作到代码整洁开始演化，这个阶段我们度量重点指标为代码重复度，业界关于重复度的指标是10%, 映射到质量分中的数据为重复度质量分，即重复度超过10%，质量分为0，借助质量卡点，要求重复质量分小于1分的项目不允许流转到下一开发阶段。

阶段3: 质量内建

代码治理之后是质量内建，该阶段的目标开发提交的存量功能都是有单测保证的，增量功能都是经过单测覆盖的。这个阶段我们度量重点指标为单测通过率和单测覆盖率，因此我们调整质量权重，单测通过率权重 5增加20，阈值100%，单测行覆盖率 5增加15分，阈值30%。

阶段4: 设计质量

这个是综合比较的阶段，我们引入了安全风险扫描，代码审计，开源协议扫描等新的检测手段，再结合单元测试通过率、单元测试覆盖率、静态代码质量等原始指标，综合的评估一个项目代码的设计质量，是在固化前3阶段的成果之上，对代码质量的一个更高追求，我们也正在为之奋斗！