快手流水线检查质效提升实践：Mulan通用代码分析服务

原创快手大前端技术快手大前端技术

2025年03月12日 11:02

导读

在当今快速发展的科技环境中，工程代码质量与迭代效率的提升已成为企业保持竞争力的关键因素。随着快手业务快速发展、代码量的迅猛增长，内部代码准入流水线检查质效已长期面临较大压力和挑战。过去两年时间里，为了提升准入流水线检查质量、合码效率，快手基础架构团队推出「Mulan 通用代码分析服务」，针对检查质效长期面临的痛点问题一一突破。本文将从快手流水线检查曾经面临的问题、Mulan 定位及演进思路、Mulan 流水线质效提升实践、总结及展望等几个方面，讲述 Mulan 在快手准入流水线检查质效提升上的实践思路。

一、项目背景

1.1 流水线检查质效提升的意义

快手发展至今，工程量和代码量迅猛增长，给现有的代码质量管控、合码效率带来了极大的挑战。随着业务快速发展，研发团队面对日益复杂的项目需求和代码架构，如何保证软件开发的质量和效率已成为关键问题。代码准入流水线检查质效的提升不仅关乎产品的稳定性和用户体验，更直接影响研发的工作效率，从而影响企业的市场竞争力。

在这种背景下，传统分散的代码质量管控工具、无限增长的代码准入检查项已对快手工程发展造成了极大压力。代码质量的劣化、合码效率的减慢，让快手的线上稳定性也面临较大挑战，近乎一半的研发都在反馈开发效率受到的负面影响。因此，急需一种关于流水线检查质效的长期保障机制，能够对检查质量、合码效率进行有效的管控，同时也能适应业务快速发展的各类诉求。

1.2 流水线检查质效面临的问题

经过多年发展，快手内部沉淀了一套复杂的代码准入流水线检查体系，包含了较多分散的静态检查工具，所有客户端代码必须经过流水线检查才能合入工程，这套检查体系持续为双端工程拦截了成千上万问题，发现了一些安全隐患，一定程度上保障了良好的工程质量，是快手客户端工程健康发展必不可少的关键流程。但是，随着系统迭代，近两年流水线检查不断面临检查质量和效率上的双重挑战，已然有些不堪重负。

根据 2022 年底快手内部研发工具链 NPS 调研数据分析，在数百条客户端反馈中约 50% 研发提及流水线代码检查和持续集成问题，主要集中在检查效率、规则开发成本、检查质量监控方面。

问题1：检查效率低

快手业务复杂，客户端双端并行开发人员众多，尤其封版当天各端 MR 合入数量占比高达 40% ~ 50%，机器算力不足导致任务排队，造成封版前代码准入流水线压力剧增。NPS 反馈中，研发对于流水线执行效率有较大意见，认为耗时过长、节点多且乱、流程繁琐，整体体感不佳。

静态检查阶段为双端流水线主要的耗时阶段，此前双端平均耗时均在 30 分钟左右，这意味着开发合入代码前需要至少预留出半小时以上时间！

问题2：规则开发成本高

不同技术栈、不同使用场景、不同检查阶段都有各自的一套静态检查基建，框架多但并没有形成合力，各自为战，导致业务新增、维护检查规则的成本非常高。当涉及到多端规则开发时，需要去熟悉不同框架不同语言、来回切换多个工程，规则也无法复用。

以上这些成本问题导致规则开发需要大量人日，而在实际业务发展中我们发现非常多代码稳定性、安全性、规范性问题都需要依靠检查规则来保障，规则开发受限导致规则需求堆积严重，无法快速支撑业务发展过程中提出的检查需求，尤其是稳定性相关规则，这也间接给工程质量造成了一定的隐患。此前快手客户端规则加起来仅有 100+ 条，相较业界其他公司存在一定差距，规则开发成本过高，增长趋势较为缓慢。

问题3：检查不透明

快手核心工程代码准入虽然都开启了静态检查，但基建混乱不成体系，对于检查规则的执行耗时、稳定性、误报率、修复率等均没有数据统计，也没有监控体系，整个代码检查完全是个黑盒。规则质量无法保证，服务质量更没有保障，没有全盘衡量静态检查质量、代码质量的能力。

从下图可以看到，以前的检查服务出问题，基本要靠开发反馈，效率低且用户体验不好：

基于以上3个突出问题，我们在不断思考，是否能提供一种通用代码分析服务？能够统一掉各技术栈、各应用场景、各检查阶段的代码检查基建，将规则统一管理起来，提供高效简洁的开发模式，并在框架内部集中实施优化策略去提升检查效率？于是，Mulan 应运而生。

二、Mulan定位及演进思路

Mulan 是通用代码分析服务，同时也是检查规则管理框架，面向工程质量，提供了一套包含分析、度量、监控的全流程服务。目标在于建设统一高效的代码检查服务，提升流水线检查质效，保障工程质量。具有如下特点：

规则运行高效：通过规则粒度和流水线节点粒度的按需触发机制，最大限度不跑无用检查；框架内部提供增量检查、云端结果复用等策略，大幅提升运行效率。
规则开发高效：统一通用基建，开发过程无需关注输入分析、代码扫描、问题上报等共性阶段，只需专注检查逻辑即可。
服务可观测：服务运维可监控，规则质量可观测。
应用场景广泛：支持多种编程语言及多平台技术栈，可应用至不同流水线模型中；支持本地检查、准入流水线检查、合入后检查、版本回归检查等多阶段，全流程跟踪问题发现、修复与漏出。
扩展性强：支持以插件形式接入其他检查框架来增强代码分析能力，并对插件检查规则进行统一管理与运维。

Mulan 从诞生到应用至多个技术栈经历了一年多的时间，从4个大的发展阶段一步步演进而来，最终实现了流水线检查质效大幅提升，也顺利从客户端推广至快手动态化及部分前端业务领域。

三、Mulan流水线质效提升实践

下面从流水线检查质效面临的三大问题，我们看 Mulan 是如何分析并逐一攻破的：

3.1 检查效率提升

通过实践我们发现，即使只是修改工程里的 README 文件，准入流水线也几乎跑了所有检查节点，这显然是不合理的。不跑无用检查是我们首要想到的思路，实际上我们流水线里早已有此类设计，前一阶段的 mr 分析会调度后续节点，在此基础上，我们分析了流水线运行数据，得到了各节点触发率，发现：绝大部分节点触发率都高达 99% ！这其中显而易见有较大的提升空间，于是 Mulan 在设计之初首要考虑了按需触发的思路。

思路1：按需触发

规则粒度按需触发：在 Mulan 的规则开发中，首先需定义的就是规则的检查范围是什么。Mulan 中规则叫 Detector，Scope 则是 Detector 关注的检查范围。Mulan 内部分析 MR 输入拿到目标文件后，会首先逐一判断待运行 Detector 列表的 Scope 和当前目标文件是否匹配，从而快速决策哪些 Detector 应该运行，以此来避免无用检查。Scope 定义并不局限于文件类型，还可以是文件目录、模块或自行写判断逻辑，可灵活扩展、多规则复用。

节点粒度按需触发：快手的准入流水线中，每个节点包含了一批规则。前面讲到，静态分析阶段的各个节点，受前一阶段 mr 分析节点的调度；这个设计的初衷是好的，但存在较大的弊端：规则的增删与 mr 分析完全脱钩，规则开发者很多时候并没有意识到需要更新分析策略，导致分析策略长期不迭代，最终 mr 分析基本失去了作用。

Mulan 接管流水线后，mr 分析完全可以自助实现。Mulan 会自动获取节点待运行的 Detector 列表，判断 Scope 从而得到真正需要运行的规则，进而判断出哪些节点应该运行。这样做的好处是：规则开发者完全不需要关注 mr 分析节点，只要定义好 Detector 的 Scope，Mulan 就能自动更新分析策略，最大限度降低节点触发率。

思路2：增量检查

节点运行效率低，观察到的第二个现象是每次提交代码，即使只是个很小的改动，都会触发整个流水线重新检查，且检查 diff 范围是整个 MR。这里是否可以缩小范围只检查当前 commit 提交的 diff 呢？

基于此，Mulan 内部做了增量检查设计。Mulan 执行检查后会上报检查结果至服务端记录；当有新 commit 提交时，会首先请求增量接口，由服务端往前追溯干净（即未检出问题）commit 并返回给 Mulan 缩小后的 diff 范围，从而实现代码变更的增量检查，大幅减少待分析的文件数量，以此降低耗时。另外，若触发检查的 commit 相同则会直接复用云端结果。

提升效果

通过以上的优化策略，Mulan 最终达成了较为不错的检查效率提升效果：

准入流水线单节点检查耗时：双端 80% 节点耗时 P50 降幅超 50%。
准入流水线静态检查相关节点耗时最大值：iOS 下降 80%，Android 下降 24%。

3.2 规则开发成本优化

关键设计：阶段复用

一般来说，开发一个检查规则有以下4个阶段：

输入分析：包括 MR 分析、工程分析、目标文件分析、配置解析等内容。
代码扫描：根据规则需求，以文件、文本、Git Diff、AST 语法树等不同维度扫描代码，获取想要的代码信息。
规则检查：根据上述输入信息，选择合适维度扫描代码，编写规则，识别代码问题。
问题上报：将问题统一组织成不同形式上报，例如上报至流水线、生成 Json 格式报告等。

原来的规则开发，基本需要自行实现上述整个流程，包括代码扫描等复杂阶段，十分耗时。Mulan 设计之初，便将这些阶段清晰划分，每个阶段都支持自定义扩展，并支持灵活组合，以满足不同的需求场景。有了通用稳定的输入分析服务、各类不同场景的代码扫描器和问题上报器，规则开发者只需要选择合适的扩展进行组合，核心关注规则检查逻辑的开发即可，最大限度做到阶段复用，大大节省开发成本。

核心打法：统一基建

Mulan 基建能力完善后，快速接管了快手主站客户端、动态化及前端的各项检查，并支持了多个大型活动的特殊化检查工作，实现了各平台技术栈的基建统一。现在，无论是质量提升，还是故障复盘，大家第一时间都想到沉淀 Mulan 规则，越来越多的人上手 Mulan 贡献规则，多端之间也可直接复用规则，再也不需要频繁熟悉和切换多个工具环境，实实在在为规则开发提效！

规则开发/测试/上线流程上，Mulan 提供了较多便利工具及服务。针对业务频繁提出的精细化需求，提炼核心通用功能进行统一基建完善，让大家低成本快速实现。

优化效果

Mulan 通过阶段复用、统一基建、轻量语法等能力，大幅降低规则开发成本。正则类规则实现了 0.5 人日内，不写任何代码从零上线一条规则；轻量语法则扩展了新的 AST 语法结构树分析能力，为语法分析类规则提供了更为快速的新选项，开发成本从原来的 5~10 人日下降至不到 1 人日！

规则增长趋势上，此前数年仅有 100+，Mulan上线半年后就涨了一倍，截止目前已发展至约 400 条，并且还在持续增长中。

3.3 检查度量与监控体系

Mulan 统一基建后，可以非常方便对所有规则进行统一管理和维护，于是我们快速搭建了规则度量体系、服务监控体系：

规则度量

监控体系

四、总结与展望

Mulan 作为快手内部迅速发展的通用代码分析基建，现接入工程数量多达 400+，规则数量从之前的 100+ 上涨至约 400 条，月均执行检查数量多达十多万次，月均检出问题去重数量多达四万多个，保障工程质量同时较大幅度提升了研发效率，是快手流水线质效提升的较好实践之一。

Mulan 发展至今，已逐步形成了庞大的服务系统，有了一定的插件市场和规则体系，也覆盖了研发流程的各个场景：

未来，Mulan 依旧致力于打造快手最强大的通用代码分析服务，进一步增强代码分析能力，持续提升工程质量，为产品稳定性保驾护航。同时，Mulan 也在积极探索 AI 辅助提升工程质效，引入智能 Code Review 分析审查代码，积极拥抱工具智能化发展！

相关阅读

- END -

继续滑动看下一个