随着公司业务的快速发展，前端平台作为研发职能部门，在高效支撑业务迭代的同时，前端新建的应用不断增加，截止到2023年5月在Uraya平台统计的各业务域的应用（B端+C端）总数已经达到170多个，发布流程中出现问题的风险逐步显现，稳定性问题逐步突出。为了更好的维护应用的代码，解决潜在的稳定性问题风险，2023年6月做了前端大仓的技术调研并在7月开始试行前端大仓的研发模式，在2024年年初开始对前端大仓应用的稳定性进行体系化治理，近2年时间的治理，前端大仓的应用无论在代码质量还是流程统一上都达到了一定的稳定程度，应用稳定性的治理达到了不错的效果，从未出现因大仓稳定性治理导致的线上问题。
前端大仓在试行之后，经过在迭代的持续性治理，已经形成了一套完整的稳定性治理流程体系，如下：
通过定义指标 -> 治理目标制定 -> 跟进过程 -> 治理结果复盘不断的迭代循环治理，形成一个闭环，且各业务域也在不断的调整治理目标，直到最终达成平台的治理目标，使得大仓各应用的稳定性的治理都能达到不错的效果。
截止目前，前端大仓的应用已达200多个，代码行数已经达到550多万行， 如何提升如此体量的代码质量和应用稳定性是一个相对比较有挑战的事情。经过早期半年的试行，基于大仓代码标准化以及研发流程标准化的建设，逐步形成了5大可衡量的治理指标：Git元数据的大小、代码质量分、研发流程卡点、Lint error质量分、应用代码重复率，如下：
大仓应用的稳定性基本上都是围绕上面5个指标来进行治理的，在逐步推进治理的过程中，大仓应用的代码稳定性也在不断的提升，当达到一定程度的时候，各应用的稳定性也会达到一定的程度趋于平稳。
基于大仓代码的标准规范以及统一的研发发布流程，且在每个季度持续推进治理下，各业务域的治理指标都有显著的提升，进而提升了前端平台大仓应用整体的稳定性。具体成效如下：
前端大仓自试行之后，Git元数据就在持续的递增，截止到2024年年底，Git元数据的大小已经接近1G，本地的部分Git命令执行时间超过5秒，MR变更及代码回合经常被非当前业务变更的文件困扰，影响了大仓应用发布的稳定性。为了解决这些性能问题，对Git元数据的大小做了性能优化，主要事项包括：
通过上面的技术实现，彻底解决了Git元数据持续递增的性能问题，使得MR阶段的代码CR更加的清晰，避免了因过多代码提交记录带来的CR不清晰、回合代码不清晰导致出现线上问题的风险，提升了应用发布的稳定性。
应用代码质量分是衡量应用代码质量的重要指标，其中主要包含大文件、函数复杂度、HTTPS检测、敏感词检测、安全检测、前端运算和魔数这些指标得分来体现应用代码的质量，基于Uraya平台的规则统计逻辑，每个迭代都会对应用的代码进行扫描并做质量分的统计，如下：
同时也可以查看应用质量分各维度指标的得分情况，具体详情信息如下： 
每个季度初期会根据不同业务域应用的质量情况来制定当前季度可达成的质量分目标，并且在季度末以此目标来最终复盘应用质量分的治理情况，如下是2025年Q3季度的整体质量分治理情况：
应用质量分的治理有一个标准线，高于80分的应用说明代码质量已经比较好了，后续再投入时间治理的话，ROI不高，故应用质量分超过80分的业务域常态化治理即可，不用专门花时间去做治理。在Q3结束之后，前端平台所有的业务域基本都达成了80分的标准线。
目前前端大仓已经集成了上百个应用，很多应用都有各自的Lint规则配置以及代码规范配置，特别是在早期基于样板间创建的应用，这个现象尤为明显。在大仓里面，如果每个应用还是按照各自的规范去开发的话，那么当研发轮岗或者各域之间互相借调的时候，因代码风格的不一致带来的熟悉上手成本、IDE规则配置成本等这些都会比较高，且研发效率低下，这跟之前单个应用仓库开发没什么区别。因此对大仓下所有应用的代码规范做了统一，研发编写的代码都需要符合标准规范，这样不仅提升了应用代码的稳定性，也提升了平台轮岗、借调研发的编码效率。主要的代码标准规范如下：
在大仓中有顶层目录的基本规范、应用目录下的代码规范以及不同技术栈的代码规范，其关系如下：
在研发本地提交代码的时候，会触发git钩子函数对变更文件的代码进行校验，确保提交的代码是符合标准规范的，并且对Lint error质量分定义了治理分记分规则，总分16.12分，代码提交的error错误数各区间得分如下：
在每双周的平台周会上进行治理情况的同步，同时在季度末复盘当前季度的整体达成情况，如下是2025年Q3季度各业务域的lint质量分治理情况： 
Lint error质量分的治理也有一个标准线，高于9分的应用说明代码标准规范已经比较好了，再专门投入时间治理的话，ROI不高，故应用的Lint error质量分超过9分的业务域都是常态化治理即可。在Q3结束的时候，前端平台所有的业务域都达成了9分的标准线。
为了避免研发本地的一些不规范流程操作带来的线上稳定性问题，在应用测试环境的构建发布流程新增流程卡点，如下所示： 
同时在构建发布流程中保留研发流程卡点的情况下，在MR阶段也新增了质量分的卡点，只要检测出有强卡的情况下，就不允许合并到release分支，确保了合入代码的质量和标准规范，如下图所示： 
基于大仓应用的研发流程，主要有以下流程卡点：
通过研发流程的强卡和弱卡进一步规范研发流程的操作，截止到目前为止，强卡次数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语言在高并发高可用系统中的实践与解决方案｜得物技术
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
微信关注我们
转载内容版权归作者及来源网站所有！
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。
为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。
Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。
扫码在手机上查看文章
扫描二维码，手机阅读更方便
有任何问题或合作意向欢迎联系我们
Email: 99873273@qq.com
QQ: 99873273