酷家乐质量效能 代码度量平台开发实践

酷家乐质量效能 · 2020年06月11日 · 最后由 jh41436 回复于 2021年04月28日 · 2053 次阅读

背景

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

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

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

目标

平台目标:
1、代码优化的依据
2、衡量研发质量
3、做到质量闭环

具体实现分以下四个方面来逐步实现:
规范化: 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 红黑榜排名,通过代码质量通晒的方式来督促研发质量提升

流程卡点

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

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

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 阶段的成果之上,对代码质量的一个更高追求,我们也正在为之奋斗!

落地成果

规范化:输出酷家乐编码规范 KuJava, 统一公司编码规范

自动/流程化:
1、结合研发发布平台,嵌入发布流程,实现全公司产品发布质量卡点
2、嵌入 GitLab CI 流程实现代码自动化扫描分析

定制化: 业务组在编码规范 KuJava 的基础上可以自定义业务组特定规范,做到因组制宜。

愿景

代码门禁:守卫进入主分支的每一个 commit

结合 Git Flow,将 CD 流程的质量卡点引入 Gitlab CI 流程:

1、每次代码提交触发代码静态扫描
2、每次合并各发布分支前检查代码质量是否符合质量标准

质量左移: 测试从第一行编码开始

1、SonarLint 插件,实现在代码编码过程中的实时扫描,将问题暴露在编码阶段
2、结合 Gitlab Webhook 功能,当前代码出现致命,阻塞级别的问题时,不允许代码提交

编码 BP: 你的每一行都是编码最佳实践

1、收集 CodeReview 最佳编码实践,形成编码知识库
2、在研发内部分享最佳编码实践
3、结合 Idea 插件在编码阶段自动提示最佳实践

关注我们

酷家乐质量效能团队热衷于技术的成长和分享,几乎每个月都会举办技术分享活动(海星日),每半年举办一次技术专题竞赛分享(火星日),并将优秀内容写成技术文章。

我们尽可能保障分享到社区的内容,是我们用心编写、精心挑选的优质文章。如果您想更全面地阅读我们的文章,请您关注我们的微信公众号"酷家乐技术质量"。

如果您有兴趣了解我们的职位和团队情况,请参考最新职位招聘,并联系 caibao@qunhemail.com。感谢您的阅读!

共收到 7 条回复 时间 点赞

整个流程非常清晰,非常赞!
质效度量在实践过程中,是需要和运维部署紧密合作,感触很深

汇荔君 回复

看来您也是行家,感谢支持~

文章中提到的单元测试的覆盖率,做单测的成本其实不低的,是怎么解决这个成本和收益的问题呢?
对于单测的覆盖率不能单一去用某个数据衡量,单测的覆盖率目标是怎么做到合理的设定

汇荔君 回复

问题一 怎么解决这个成本和收益的问题呢?

在平台落地过程中, 我们也发现单测的成本问题, 不仅是研发侧为提高单测覆盖率付出的实际编码成本, 更是研发侧对覆盖率指标的质疑。

我们摸索出的可行模式: 收窄覆盖率指标, 看的见的收益

  1. 从整个 Repo 的覆盖率指标收窄为热点代码块的覆盖率指标, 热点代码块的来源是根据线上代码执行的频率选取的
  2. 从历史代码问题导致的 Bug 中, 统计出能在单测阶段发现的问题, 并以此形成单测改进规范, 推动规范落地 这样达到的目的就是让研发侧真切的感知到, 你的单测覆盖是真正跟线上功能和故障捆绑在一起的, 而不是一个 KPI 指标。

问题二 单测的覆盖率目标是怎么做到合理的设定?

从以下几个维度考量设定:

  1. 当前项目单测实际情况
  2. 当前项目的是否为核心服务
  3. 当前项目本季度的业务开发繁忙情况
  4. 覆盖率指标选取 (行/方法/分支...)

总结下来就是: 在不影响业务开发情况下的一个够得着的覆盖率指标。

您好 请问这个平台是付费的吗

jh41436 回复

使用了开源软件

HEYRIX 回复

不知道怎么使用😂 看的有点懵

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册