一、治理背景

随着公司业务的快速发展，前端平台作为研发职能部门，在高效支撑业务迭代的同时，前端新建的应用不断增加，截止到2023年5月在Uraya平台统计的各业务域的应用（B端+C端）总数已经达到170多个，发布流程中出现问题的风险逐步显现，稳定性问题逐步突出。为了更好的维护应用的代码，解决潜在的稳定性问题风险，2023年6月做了前端大仓的技术调研并在7月开始试行前端大仓的研发模式，在2024年年初开始对前端大仓应用的稳定性进行体系化治理，近2年时间的治理，前端大仓的应用无论在代码质量还是流程统一上都达到了一定的稳定程度，应用稳定性的治理达到了不错的效果，从未出现因大仓稳定性治理导致的线上问题。

二、治理体系

前端大仓在试行之后，经过在迭代的持续性治理，已经形成了一套完整的稳定性治理流程体系，如下：

• 定义指标： 在前端大仓monorepo研发流程模式下定义应用稳定性治理目标，治理目标是经过各业务域统一对焦且切实有效的；
• 治理目标制定： 在每个季度初，各业务域根据应用稳定性治理结果重新定义治理目标，写入到OKR中，作为当前季度的稳定性治理事项，各业务域因应用的质量不一样，稳定性治理指标也存在一定的区别；
• 跟进过程： 在每双周的平台周会同步各业务域在迭代的稳定性治理结果，对于治理效果不太理想的业务域做适当的提醒，跟进每个迭代的治理情况；
• 治理结果复盘： 在每个季度末，OKR复盘的时候，会统计各业务域在当前季度的治理结果，通过KR目标来衡量是否达成稳定性治理目标。

通过定义指标 -> 治理目标制定 -> 跟进过程 -> 治理结果复盘不断的迭代循环治理，形成一个闭环，且各业务域也在不断的调整治理目标，直到最终达成平台的治理目标，使得大仓各应用的稳定性的治理都能达到不错的效果。

三、治理指标

截止目前，前端大仓的应用已达200多个，代码行数已经达到550多万行， 如何提升如此体量的代码质量和应用稳定性是一个相对比较有挑战的事情。经过早期半年的试行，基于大仓代码标准化以及研发流程标准化的建设，逐步形成了5大可衡量的治理指标：Git元数据的大小、代码质量分、研发流程卡点、Lint error质量分、应用代码重复率，如下：

• Git元数据的大小： 随着每个迭代各业务域代码行数的增加以及git记录的提交，大仓的Git元数据会不断增加，当增加到一定程度的时候，会对本地git命令操作、MR变更以及代码的回合产生影响，进而影响应用发布的稳定性。对Git元数据大小进行治理，能够直接提升研发效率以及应用发布的稳定性；
• 代码质量分： 对应用代码的质量通过不同的可衡量指标进行积分汇总成代码质量分，主要包括大文件、函数复杂度、HTTPS检测、敏感词检测、安全检测、前端运算和魔数这些指标得分来体现应用代码的质量。这些指标治理得好，代码质量分就越高，应用的稳定性也就越好；
• Lint error质量分： Lint error是前端代码标准规范的重要衡量指标，在大仓下的应用代码有统一的lint检测规范。对研发每次提交的代码进行Lint规范检测，获取不同的质量分，通过不同的分数区间来衡量Lint error质量分，质量分越高，应用的代码规范越好，应用的稳定性也就越好；
• 研发流程卡点： 在应用代码MR阶段和构建发布流程中，研发流程卡点至关重要，主要包括强卡和弱卡。比如对lint标准规范的检测、变更文件权限校验、分支名称检测及合法性校验等进行卡点，当出现卡点的时候，通过强卡和弱卡的手段来提示研发问题的风险，避免了一些不规范操作带来的线上问题，提升了应用构建发布的稳定性；
• 应用代码重复率： 代码重复率是体现大仓应用代码可复用的重要衡量指标，代码的复用性越好，代码的重复率就越低，可复用的代码就越稳定，进而提升应用代码的稳定性。

大仓应用的稳定性基本上都是围绕上面5个指标来进行治理的，在逐步推进治理的过程中，大仓应用的代码稳定性也在不断的提升，当达到一定程度的时候，各应用的稳定性也会达到一定的程度趋于平稳。

四、治理成效

基于大仓代码的标准规范以及统一的研发发布流程，且在每个季度持续推进治理下，各业务域的治理指标都有显著的提升，进而提升了前端平台大仓应用整体的稳定性。具体成效如下：

• 自从前端大仓试行以来，依托统一的研发构建发布流程，大仓应用从未出现过线上冒烟点和故障；
• 通过对Git元数据的大小进行性能优化，将原来大仓800M+的元数据大小减少到平均各业务域Git元数据大小60M以下， 提升了本地Git命令操作的效率，使得MR变更和代码回合更加的清晰，提升了应用发布流程的稳定性；
• 大仓应用代码的质量分从最初的74分左右提升到目前的85分以上， 极大的提升了应用代码的质量，提升了应用线上功能的稳定性；
• Lint error的质量分从最初的平均10分左右提升到目前的13分以上， 促进了各业务域应用代码标准规范的统一，不仅提升了大仓应用代码的质量和稳定性，还提升了平台轮岗、借调研发的编码效率；
• 研发流程卡点在构建发布和MR阶段上线以后，截止到目前为止，强卡次数1200多次，弱卡次数2万多次，成功避免出现线上问题隐患130次左右， 提升了应用发布的稳定性；
• 代码重复率从最初的12.5%左右降低到目前的8%以下， 在提升代码复用的同时，也提升了整体大仓应用代码的可维护性和稳定性。

五、治理事项

Git元数据性能优化

前端大仓自试行之后，Git元数据就在持续的递增，截止到2024年年底，Git元数据的大小已经接近1G，本地的部分Git命令执行时间超过5秒，MR变更及代码回合经常被非当前业务变更的文件困扰，影响了大仓应用发布的稳定性。为了解决这些性能问题，对Git元数据的大小做了性能优化，主要事项包括：

• 对Git clone命令做了二次封装，利用其实现本地缓存，二次clone时间至少减少90%左右的时间；
• 利用Git sparse-checkout稀疏检出的能力，将原来首次几分钟的clone时间减少到10秒以内；
• 通过动态化技术拆分大仓的元数据，将原来近1G的元数据减少至平均单个业务域60M以下。

通过上面的技术实现，彻底解决了Git元数据持续递增的性能问题，使得MR阶段的代码CR更加的清晰，避免了因过多代码提交记录带来的CR不清晰、回合代码不清晰导致出现线上问题的风险，提升了应用发布的稳定性。

代码质量分的统计

应用代码质量分是衡量应用代码质量的重要指标，其中主要包含大文件、函数复杂度、HTTPS检测、敏感词检测、安全检测、前端运算和魔数这些指标得分来体现应用代码的质量，基于Uraya平台的规则统计逻辑，每个迭代都会对应用的代码进行扫描并做质量分的统计，如下：

同时也可以查看应用质量分各维度指标的得分情况，具体详情信息如下： 每个季度初期会根据不同业务域应用的质量情况来制定当前季度可达成的质量分目标，并且在季度末以此目标来最终复盘应用质量分的治理情况，如下是2025年Q3季度的整体质量分治理情况：

应用质量分的治理有一个标准线，高于80分的应用说明代码质量已经比较好了，后续再投入时间治理的话，ROI不高，故应用质量分超过80分的业务域常态化治理即可，不用专门花时间去做治理。在Q3结束之后，前端平台所有的业务域基本都达成了80分的标准线。

Lint标准规范的统一

目前前端大仓已经集成了上百个应用，很多应用都有各自的Lint规则配置以及代码规范配置，特别是在早期基于样板间创建的应用，这个现象尤为明显。在大仓里面，如果每个应用还是按照各自的规范去开发的话，那么当研发轮岗或者各域之间互相借调的时候，因代码风格的不一致带来的熟悉上手成本、IDE规则配置成本等这些都会比较高，且研发效率低下，这跟之前单个应用仓库开发没什么区别。因此对大仓下所有应用的代码规范做了统一，研发编写的代码都需要符合标准规范，这样不仅提升了应用代码的稳定性，也提升了平台轮岗、借调研发的编码效率。主要的代码标准规范如下：

• TS标准规范（TypeScript语言）：@xxxxx/ts-config/base.json
• eslint标准规范（JavaScript语言）：@xxxxx/eslint-config
• stylelint标准规范（CSS样式）：@xxxxx/stylelint-config
• .prettierrc标准规范（代码格式化）& VSCode编辑器代码格式化配置

在大仓中有顶层目录的基本规范、应用目录下的代码规范以及不同技术栈的代码规范，其关系如下：

在研发本地提交代码的时候，会触发git钩子函数对变更文件的代码进行校验，确保提交的代码是符合标准规范的，并且对Lint error质量分定义了治理分记分规则，总分16.12分，代码提交的error错误数各区间得分如下：

• 0～100（包含100）个error错误： 得4.12分
• 100～300（包含300）个error错误：得2.8分
• 300～600（包含600）个error错误：得2.8分
• 600～800（包含800）个error错误：得1.2分
• 800～1000（包含1000）个error错误：得4分
• 1000-2000 (包含2000）个error错误：得1.2分
• 2000个以上error错误：得0分

在每双周的平台周会上进行治理情况的同步，同时在季度末复盘当前季度的整体达成情况，如下是2025年Q3季度各业务域的lint质量分治理情况：

Lint error质量分的治理也有一个标准线，高于9分的应用说明代码标准规范已经比较好了，再专门投入时间治理的话，ROI不高，故应用的Lint error质量分超过9分的业务域都是常态化治理即可。在Q3结束的时候，前端平台所有的业务域都达成了9分的标准线。

研发流程卡点的建设

为了避免研发本地的一些不规范流程操作带来的线上稳定性问题，在应用测试环境的构建发布流程新增流程卡点，如下所示： 同时在构建发布流程中保留研发流程卡点的情况下，在MR阶段也新增了质量分的卡点，只要检测出有强卡的情况下，就不允许合并到release分支，确保了合入代码的质量和标准规范，如下图所示： 基于大仓应用的研发流程，主要有以下流程卡点：

• 【弱卡】分支名称检测及合法性校验
• 【弱卡】Lint标准规范检测
• 【强卡】变更文件权限校验
• 【强卡】分支变更与对应应用是否匹配
• 【强卡】分支变更是否存在多个业务域或者多个应用的修改
• 【强卡】分支变更是否存在不允许修改的文件夹

通过研发流程的强卡和弱卡进一步规范研发流程的操作，截止到目前为止，强卡次数1200多次，弱卡次数2万多次，成功避免出现线上问题隐患130次左右，提升了应用发布的稳定性。

代码重复率的统计

代码重复率是衡量大仓代码可复用的重要指标，也是平台侧一直推进的治理事项，前期代码重复率的统计都依赖于研发本地跑脚本看数据，每个迭代结束才清楚治理效果。为了便于研发在本地能够实时的查看代码质量分的治理结果，提供了VSCode插件来实时统计结果，如下功能所示：

研发通过点击上面的治理小助手，就能实时查看当前分支的治理效果，极大的提升了治理效率。同样在每双周也会进行代码重复率的同步，在季度末会进行治理目标的复盘，如下是2025年Q3季度各业务域的代码重复率治理情况： 代码重复率的治理也有一个标准线，低于6%的应用说明代码复用已经比较好了，再专门投入时间治理的话，ROI不高，故应用的代码重复率低于6%的业务域都是常态化治理即可。在Q3结束的时候，前端平台部分业务域已经达成了低于6%的标准线。

六、治理总结

前端平台通过试行大仓的研发模式，系统性地开展了应用的稳定性治理工作。自2023年7月试行、2024年初体系化推进以来，围绕五大核心指标--Git元数据大小、代码质量分、Linterror质量分、研发流程卡点和代码重复率，构建了“定义指标→制定目标→过程跟进→结果复盘”的闭环治理体系。通过统一代码规范、优化Git元数据性能、强化流程发布卡点、提升代码复用等举措，显著提升了大仓应用整体的稳定性。截至2025年Q3，各业务域普遍达成质量标准线，大仓应用从未发生因治理导致的线上故障，实现了高效、稳定、可持续的前端大仓应用研发稳定性治理体系。 随着目前大模型的不断迭代，后续结合AI智能体对研发流程进行稳定性加固，相信大仓应用的稳定性会更上一个台阶。

往期回顾

1.RocketMQ高性能揭秘：承载万亿级流量的架构奥秘｜得物技术

2.PAG在得物社区S级活动的落地 

3.Ant Design 6.0 尝鲜：上手现代化组件开发｜得物技术

4.Java 设计模式：原理、框架应用与实战全解析｜得物技术

5.Go语言在高并发高可用系统中的实践与解决方案｜得物技术

文 /玉润

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。