随着公司业务的快速发展，前端平台作为研发职能部门，在高效支撑业务迭代的同时，前端新建的应用不断增加，截止到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业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。
Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。
Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。
Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。
扫码在手机上查看文章
扫描二维码，手机阅读更方便
有任何问题或合作意向欢迎联系我们
Email: 99873273@qq.com
QQ: 99873273