前言

春節剛歸來，我們不搞那么燒腦，先來一篇淺顯易懂的文章，期望給大家帶來一些新的解題思路。

背景

過去多年無論是一款插件推廣，還是組件庫統一，無論是一次機制流程制定，還是前端工程化體系建設，相信很多同學與我一樣，在跨團隊方案推廣統一過程中，前期無論做好多詳實的準備，最終都會有一種未竟全功的感覺。

推廣過程中，總會有人擺出歷史包袱過重這一攔路虎“說服”我們，比如”我這項目不維護了，無需升級“，”我這項目框架太老舊了，無法升級“，或兩者兼有之，到底改哪些項目，多取決于雙方自行判斷，說穿了其實是雙方“非不能也，乃不欲也”。

危害

一方面前端項目下線充滿不確定性，業務不維護不代表頁面無訪問，舊有項目中總有一些頁面殘留，需要長期持續跟進。

另一方面過去多年前端技術生態快速向前發展，造成了不同部門、時期，從jquery、vue2、vue3、react、angular到webpack3、4、5、gulp、vite等前端基建五花八門的場景，僅23年我們團隊就先后接入過webpack5、vite、pinia、rspack等前端架構局部優化，跨團隊統一需要做大量兼容工作，全量統一困難。

前端項目的業務和技術特點，造成了前端項目數量基本越壘越多，每個項目總有幾個有流量的頁面時不時跳出來惡心人。造成了前端基建越來越龐雜，兼容成本偏高，總是不能全量升級。形成了前端項目獨特的長尾化問題，項目長尾化，基建長尾化，團隊意識長尾化。隨著時間延續會帶來升級維護困難和難以言表的線上偶發驚嚇。

根源和解決思路

基于我司經驗，問題產生根源一是前端團隊資源有限，并不能覆蓋全部項目；二是沒有統一標準，項目缺乏統一標準管理，各團隊自我決策改動范圍；三是缺乏強制機制，并不能保證完成效果和時間。

資源有限是個基本無法解決的問題，我們只能從標準和強制機制兩個角度去解決，基于此我們針對性的制定了轉轉自己的項目動態分級標準和強制倒逼機制。

項目動態分級

分級指的是用客觀統一的數據標準反映項目重要性，規避主觀評判。動態指的是隨著時間延續，項目走過新建、迭代、維護、下線的生命周期，客觀數據也隨生命周期波谷、波峰、波谷往復更替。項目動態分級的最大好處是將有限資源聚焦在重點項目上。

以過去我司推進項目代碼規范為例，我們設計時采用項目月活躍分支數、月代碼提交行數、項目用戶日訪問量幾個指標確定項目級別；

動態項目池

比如只有同時滿足日訪問量UV高于10000、日PV高于100000、月活躍分支數多于4個、月代碼提交行數多于200的項目才確定為移動端重點項目，其它項目為非重點項目，每日或每周可以跑定時任務更新項目分級數據，具體數據可以通過拉取git api和公司前端埋點數據獲得。

針對重點項目，可以制定2-4個月的改造時間節點和達標標準，非重點項目可以不做改造或制定其它策略。

我司前端項目數不到千，僅將項目分成重要和不重要兩個級別已經夠用，如場景有必要，也可將項目進一步拆分為更多級別。

指標邊界值

大家可能對上面UV > 10000或月活躍分支數 > 4 等指標邊界值是怎么確定的感興趣？

說一下我們的思路，相信每個前端團隊過去都手動收集過團隊中的重點項目有哪些，這些手動數據可以作為我們的衡量基礎，可以不斷嘗試調整我們的指標邊界值，計算出的重點項目一般達到基本覆蓋我們手動收集的95%以上重點項目即可，以此來確定邊界值指標，一般結果肯定會大于我們的手動集，大家拿到結果可以人工再去分析下具體項目，基本能夠發現多出來的項目大部分都是真實的重點項目，大部分都是因為我們談到的歷史包袱問題，不提罷了。

注意如果動態項目池，每日或每周都有較大變化，可能是你的指標不太合理，可以考慮擴大或縮小邊界值來解決。另外注意突然進入重點動態項目池的項目，一般下個周期有可能就波動出去了，此類項目可以不做處理，也可推動解決，留好一定改動時間即可。

多指標好處

相比單指標確定邊界值，多指標有哪些好處呢？

多指標好處一個是覆蓋全部場景，比如我司移動端項目框架為Vue，有大量用戶訪問，中后臺項目技術棧為React，沒有大量用戶訪問。如果僅使用用戶訪問量指標，中后臺項目全部會被排除在重點項目外，如果僅使用項目活躍度，移動端最看重的用戶訪問量不被納入，項目區分度不夠，但是兩者相結合，恰好能覆蓋移動端和PC端的全量場景。

另一個是多指標得出的結果穩定性更好，不會因單指標劇烈變化造成結果波動太大的情況，比如去年618和雙11期間，盡管我司用戶訪問量大增，但重點項目集并沒有什么變化。

強制倒逼機制

另外怎么確保deadline無延期呢？

我司采用的解決辦法是與上線環節綁定，通過強攔截和審批攔截的方式，確保各團隊能在最終時間節點之前，完成全部項目的改造。除此之外，強制機制能夠倒逼各團隊提升生產率，將很多重復性工作自動化，比如上文說到的代碼規范，總會有同學梳理出一套本地自動化方案，幫我們完成配套建設。當我們標準達成、配套健全后，就可以考慮下擴大范圍或者提高標準的事情了。

另外大家需要注意，跨組推進工作中很重要的一點是前置溝通，給同學們留下足夠的時間，比如2-6個月，達成時間共識很重要，不要自覺良好一刀切，想想過去經歷的很多跨組項目，半年能徹底搞完就很不錯了。

自循環機制

思路&基建復用

本文談到的整套分級和強制思路，后續逐步復用在我司代碼重復度、復雜度、線上異常治理、性能指標等多項跨團隊公共事項落地中，有些指標直接復用同一套項目分級標準即可，有些指標需要一定的改動，比如性能指標，就從重點項目，變為重點頁面即可，大部分基礎能力和解決問題的思路仍可復用。

總結

保持公司各團隊基建、標準、機制統一，長期看是非常有必要的事，但過去受制于歷史包袱問題這一隱性攔路虎，前端很難做到跨團隊統一方案的效用最大化，總會留下一些尾巴，本文通過轉轉過去的實踐，給出了項目分級和強制機制的解體思路，非常適合前端資源并不那么充足的公司，至少能夠保證公司重要的項目長期標準統一。

另外整個思路的落地，除標準制定外，還涉及到數據抽取、各指標檢測、CICD集成、報警機制、系統開發等多方面的具體工作，每一部分都能作為一個單獨的模塊去做分享，比如代碼規范涉及到的項目代碼增量存量檢測、代碼復雜度、重復度檢測，線上異常治理涉及到的實時報警策略、錯誤分級策略等，因篇幅關系，本文不再贅述。