一、治理背景
隨着公司業務的快速發展，前端平台作為研發職能部門，在高效支撐業務迭代的同時，前端新建的應用不斷增加，截止到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語言在高併發高可用系統中的實踐與解決方案｜得物技術
文 /玉潤
關注得物技術，每週更新技術乾貨
要是覺得文章對你有幫助的話，歡迎評論轉發點贊～
未經得物技術許可嚴禁轉載，否則依法追究法律責任。
