得物效率前端微應(yīng)用推進過程與思考
一、背景
效率工程
隨著業(yè)務(wù)的發(fā)展，組織規(guī)模的擴大，越來越多的企業(yè)開始意識到協(xié)作效率對于企業(yè)團隊的重要性，甚至是決定其在某個行業(yè)競爭中突圍的關(guān)鍵，是企業(yè)長久生存的根本。
得物效率工程運用產(chǎn)品、技術(shù)、數(shù)據(jù)等手段，全面提升公司的效率。在管理效率、協(xié)同效率、跨團隊溝通效率、產(chǎn)研協(xié)作效率、辦公效率等各方面持續(xù)探索，高效驅(qū)動公司發(fā)展。
效率工程的業(yè)務(wù)場景
上面提到，效率工程為提升企業(yè)協(xié)作效率而生，因此會面臨大量中后臺應(yīng)用場景。
這些中后臺應(yīng)用體現(xiàn)為「PC 站點、H5 站點、飛書應(yīng)用、特定機器環(huán)境」等，面向所有內(nèi)部員工和部分外部用戶。
在面向多類型用戶和使用場景等條件下，效率工程技術(shù)產(chǎn)品在穩(wěn)定性、體驗、擴展性等方面面臨的挑戰(zhàn)非常多。
效率工程面臨的問題
效率工程主要的業(yè)務(wù)形態(tài)是「PC 站點的大型中后臺應(yīng)用」，此類應(yīng)用的布局大多數(shù)是這樣的：
圖片
針對這類場景，有此類產(chǎn)品研發(fā)經(jīng)驗的同學(xué)，對其面對的問題也會比較熟悉：
- 依賴管理方面。非 monorepo 類倉庫下，對于只有一個 package.json 對依賴管理，底層依賴如 antd 等版本升級困難，因為回歸成本很高。
a.個別底層依賴的升級是難以避免的，尤其是涉及穩(wěn)定性、可維護性、用戶體驗方面，在某個節(jié)點會爆發(fā)問題影響線上
- 代碼耦合度方面。微前端下，如果沒有做好抽象，基座和子應(yīng)用的代碼耦合度容易偏高。
- 基座通常包括：Layout、權(quán)限控制等通用模塊難免的，在基座中可能包括對特定頁面的處理邏輯，這里不再舉例
- 業(yè)務(wù)投放成本方面。有些業(yè)務(wù)的內(nèi)容區(qū)非常適合投放到多個平臺，但通常情況下中后臺應(yīng)用代碼的布局和內(nèi)容部分是強耦合的。單獨將內(nèi)容區(qū)域投放到外部平臺，要一個個處理，成本很高。
- 比如某個重報表類平臺，其報表展示能力能否應(yīng)用在更多平臺上，其投放能力是最重要的影響因素
經(jīng)過調(diào)研后，我們引入微應(yīng)用來解決目前遇到的問題：
微應(yīng)用
一個基于“monorepo & 微前端 & 基座與業(yè)務(wù)分離”的、包括“文檔 & 工具”的一套體系化降低研發(fā)成本和提升用戶體驗的技術(shù)產(chǎn)品。
這是面向得物效率工程業(yè)務(wù)場景下，我們對微應(yīng)用的定義。
系統(tǒng)案例：得物學(xué)習(xí)平臺
得物效率工程的學(xué)習(xí)平臺，是面向得物員工、勞務(wù)人員、鑒別師、客服等人群的大型中后臺應(yīng)用，產(chǎn)品形態(tài)是 PC / H5 / 飛書應(yīng)用等。是非常典型的適用于「微應(yīng)用」推進的項目。
圖片
依賴管理方面
學(xué)習(xí)平臺原來是非 monorepo 結(jié)構(gòu)，只用一個 package.json 做依賴管理，底層依賴 antd 等的版本極難更新，很難享受到最新版本的快樂。
代碼耦合度方面
學(xué)習(xí)平臺 Layout 和各個頁面內(nèi)容部分代碼是強耦合的，Layout 中也有部分頁面的業(yè)務(wù)邏輯。
業(yè)務(wù)投放成本方面
學(xué)習(xí)平臺的多個頁面對外投放是整體性投放，需要對 Layout 做特殊處理、權(quán)限特殊處理等方式處理后，才能開始投放，投放成本高，而且投放方案不通用。
二、問題分析
Why：為什么做？為什么這樣做？
- 中后臺應(yīng)用越來越臃腫已成為共識
- 中后臺需要在功能越來越多的情況下，輕量化地迭代
- monorepo 配合微前端，是中后臺應(yīng)用輕量化迭代的有效方案
Who: 用戶是誰？
- 業(yè)務(wù)前端：能夠快速理解遷移方案、低成本使用配套工具完成遷移、有充分的 Q/A 文檔介紹
- Leader：能夠通過看板等產(chǎn)品、結(jié)合指標，快速判斷遷移后的工程質(zhì)量，在長期維護狀態(tài)下保證工程質(zhì)量不快速下降
What：做什么？
- 最佳實踐文檔：面向業(yè)務(wù)前端，要求通俗易懂，業(yè)務(wù)前端可以在 0.5D 內(nèi)快速理解整個方案
- 遷移工具：提供一個工具，幫助開發(fā)者快速完成遷移
- 巡檢看板：查看各類指標，如依賴版本是否過期、公共模塊位置是否合理等
When：什么時候做？
- 一個中后臺項目子應(yīng)用超過 X 個，感官越來越臃腫的情況下，可以考慮做微應(yīng)用化了
- 想在中后臺項目前期打好基礎(chǔ)，便于后續(xù)迭代提效，可以考慮使用微應(yīng)用了
Where：在哪里做？
- 解釋：很顯然這不是在說物理位置，在研發(fā)流程中，這個工具該處于什么位置
- 遷移中：在業(yè)務(wù)開發(fā)者本機執(zhí)行遷移動作、飛書文檔完成背景介紹
- 遷移后：有在線的巡檢平臺可以：執(zhí)行巡檢、查看巡檢報告
How：如何做？
- 要同時進行 monorepo 化和微前端化，工作量大、操作復(fù)雜、穩(wěn)定性保障難度大
- 第 1 步：以 1 個項目試點，跑通流程、輸出“最佳實踐（初版）”、輸出“遷移工具（初版）”
- 第 2 步：以 1 個項目驗證全套方案，輸出“最佳實踐（修正版）”、輸出“遷移工具（修正版）”
- 第 3 步：以 1 個項目完成全套方案，輸出“最佳實踐（完整版）”、輸出“遷移工具（完整版）”
- 第 4 步：更多項目接入
三、明確目標
根據(jù) SMART 原則，我們制定了如下目標（時間限制在 3 個月內(nèi)）：
1. 降低微應(yīng)用化遷移成本，中大型應(yīng)用的微應(yīng)用化遷移耗時降低 30%
耗時降低計算公式：1 - (有 SOP 時微應(yīng)用化遷移估時 / 無 SOP 時微應(yīng)用化遷移估時)
2. 降低學(xué)習(xí)平臺維護成本，管理端和學(xué)員端公共依賴升級時的測試耗時降低 50%
耗時降低計算公式：1 - (微應(yīng)用化后的測試估時 / 微應(yīng)用化前的測試估時)
四、推進方案
經(jīng)過以上分析，我們的推進方案在「輸出、里程碑、技術(shù)架構(gòu)、測試方案、效果預(yù)估」等方面進行了確認。
輸出
1. 面向業(yè)務(wù)開發(fā)者
a.《效率前端微應(yīng)用最佳實踐》文檔：幫助業(yè)務(wù)開發(fā)者可以在 0.5D 理解遷移所需的各類背景
b.「微應(yīng)用遷移技術(shù)產(chǎn)品 monopower」：幫助業(yè)務(wù)開發(fā)者完成應(yīng)用 monorepo 化過程 90% 的工作量
2. 面向 Leader
a.「在線巡檢能力和報告」：幫助 Leader 查看項目完成微應(yīng)用遷移后，工程質(zhì)量是如何的，這里包括了一系列的指標
里程碑
圖片
如上圖，里程碑整體分為 2 個階段：
第一階段，通過業(yè)務(wù)的少量落地完成方案驗證，側(cè)重在驗證
第 1 步：以 1 個項目試點，跑通流程、輸出“最佳實踐（初版）”、輸出“遷移工具（初版）”，落地 1 ~ 2 個頁面
第 2 步：以 1 個項目驗證全套方案，輸出“最佳實踐（修正版）”、輸出“遷移工具（修正版）”，落地 3 ~ 10 個頁面
第二階段，業(yè)務(wù)全量遷移，側(cè)重在業(yè)務(wù)落地
以 1 個項目完成全套方案，輸出“最佳實踐（完整版）”、輸出“遷移工具（完整版）”，落地該應(yīng)用全部頁面
技術(shù)架構(gòu)
1. 迪米特法則
即最小知識原則，在 SOLID 設(shè)計原則中符合 「Single，單一職責(zé)；Open-Close：開閉原則」的思想。
我們在考慮微應(yīng)用技術(shù)架構(gòu)所具備的特征時，更注重簡單、可靠、閉環(huán)，也就是迪米特法則。
簡單：輸出的技術(shù)產(chǎn)品和文檔，需要面向真正用戶，易于理解，使用門檻低
可靠性：業(yè)內(nèi)微前端產(chǎn)品（qiankun / wujie / micro-app / ...）對比，各自的優(yōu)缺點，是否滿足業(yè)務(wù)需求
閉環(huán)：當項目進行微應(yīng)用化后，定時巡檢和告警會觸發(fā)運行，定期掃描工程質(zhì)量并通知到相關(guān)方
2. 整體架構(gòu)
圖中綠色區(qū)域是需要開發(fā)的產(chǎn)品或文檔。
圖片
整體架構(gòu)包括以下核心模塊：
a.新增微應(yīng)用倉庫
不在老倉庫進行微應(yīng)用化改造，保證穩(wěn)定性。
b.monopower cli/server
i.一鍵改造非 monorepo 項目為 monorepo 項目
圖片
ii.掃描項目質(zhì)量，并輸出報告和告警
圖片
c.微應(yīng)用遷移最佳實踐文檔
3. 一鍵 monorepo 化
轉(zhuǎn)換過程
- 對原工程做「基于 AST 或正則」的依賴分析
- 調(diào)整目錄結(jié)構(gòu)為 monorepo
- 對新工程中代碼做「基于 AST 或正則」的引用路徑修正
比如，原工程中有 import utils from '@/utils'，新工程可能需要變?yōu)?import utils from '@monorepo/utils'
圖片
技術(shù)實現(xiàn)
a.對原工程做依賴解析后，會生成包含依賴樹的 json 文件存儲在本地
b.基于 json 文件 和 monorepo 結(jié)構(gòu)規(guī)范，生成新的 monorepo 化的工程結(jié)構(gòu)
c.基于 json 文件和 monorepo 結(jié)構(gòu)規(guī)范，對新的 monorepo 化的工程中的引用路徑做修正
圖片
多次 monorepo 化
由于學(xué)習(xí)平臺的微應(yīng)用化持續(xù)近 3 個月，期間會經(jīng)歷多次迭代。
比如 A/B/C 3 個頁面是待微應(yīng)用化的頁面，用 3 個迭代分別對 A/B/C 3 個頁面進行微應(yīng)用化。
那么，A 頁面上線后，假如第二個迭代，原倉庫依然需要對 A 頁面修改，就意味著，第二個迭代要同時上線 A/B 頁面。
為了減少回歸測試成本，我們用 monopower transfer 做了一個轉(zhuǎn)換后的 diff 展示，如果 A 頁面在兩次迭代被進行了兩次 transfer，且 diff 沒有變化，就不需要回歸測試。
測試方案
1. 兩個方案
a. 以單個路由為粒度，每次全量切換該路由的流量到微應(yīng)用版本 b. 以整個工程為粒度，按照人群/流量分布為維度，定向灰度到微應(yīng)用版本
2. 選定方案
最終我們用第一個測試方案。原因如下：
a. 學(xué)習(xí)平臺是微應(yīng)用推進的第一個驗證型項目，短時間內(nèi)全量完成改造的難度太大
b. 以單個路由為粒度，能夠逐步修復(fù)問題，驗證整體方案的可行性
3. 應(yīng)用效果
使用第一個方案，在整個微應(yīng)用落地過程中是比較順利的，平穩(wěn)地將近 40 個頁面逐批次切換到微應(yīng)用模式。
這里也頻繁用到了「推進方案 -- 技術(shù)架構(gòu) -- 一鍵 monorepo 化」中提到的“多次 monorepo 化”，利用 monopower transfer 的 diff 結(jié)果，來減少回歸測試成本。
效果評估
1. 學(xué)習(xí)平臺改造前后的工程結(jié)構(gòu)對比
改造前：
圖片
改造后：
圖片
2. 遷移前
系統(tǒng)自檢：
圖片
3. 遷移中
遷移步驟：
i.安裝命令行 monopower
ii.在當前項目執(zhí)行 monopower transfer，執(zhí)行 monorepo 化
iii.逐個頁面測試
圖片
正向依賴分析：
比如入口文件 index.tsx，可以基于該入口文件做依賴樹的可視化分析
圖片
反向依賴分析：
用于分析某個文件被哪些文件引用，用于分析該文件的重要性等
圖片
4. 遷移后
定期巡檢，輸出巡檢報告，包括且不限于「工程化配置、代碼質(zhì)量、公共依賴引用、依賴收斂、穩(wěn)定性、性能、用戶體驗」等分析結(jié)果。
巡檢工具內(nèi)部，可以結(jié)合靜態(tài)文件掃描和運行時模擬，對當前項目做全方位掃描，當然側(cè)重在微應(yīng)用方面的健康度。
五、目標達成情況
上文中提到了「微應(yīng)用」推進的目標，這里分開演示效果。
目標 1：降低微應(yīng)用化遷移成本，中大型的微應(yīng)用化遷移耗時降低 30%
耗時降低計算公式：1 - (有 SOP 時微應(yīng)用化遷移估時 / 無 SOP 時微應(yīng)用化遷移估時)
改造前
圖片
用 monopower transfer 對學(xué)習(xí)平臺進行 monorepo 化改造：
圖片
圖片
改造后
圖片
目標 2：降低學(xué)習(xí)平臺維護成本，管理端和學(xué)員端公共依賴升級時的測試耗時降低 50%
耗時降低計算公式：1 - (微應(yīng)用化后的測試估時 / 微應(yīng)用化前的測試估時)
很顯然，這是利用了 monorepo 類工程的天然優(yōu)勢：依賴隔離。
圖片
學(xué)習(xí)平臺可以針對管理端和學(xué)員端做依賴隔離，從而可以單獨升級學(xué)員端、管理端業(yè)務(wù)的底層依賴。
六、推進的經(jīng)驗教訓(xùn)
變與不變
上述推進方案確認后，剩下的就是根據(jù)各個里程碑完成對應(yīng)進度即可，因此在推進過程中，沒有遇到「進度」方面的問題。
當然在推進途中，隨時會面臨實際的技術(shù)問題、人員調(diào)整、業(yè)務(wù)壓力等，除了保持足夠的心理準備外，在“技術(shù)調(diào)研”階段，為關(guān)鍵鏈路做好多個方案對比和意外狀況的預(yù)案尤為重要。
比如，在微前端選型中，社區(qū)中有諸多方案可選（iframe / qiankun / wujie / micro-app 等），在初期擬定某個微前端方案后，如果中途遇到難以解決的問題，就需要及時復(fù)盤、調(diào)整到備選方案。
備選方案也要做足功課，這是我們在推進微應(yīng)用落地過程中的重要經(jīng)驗
Babel在實際應(yīng)用中的劣勢
在上文介紹「推進方案 - 技術(shù)架構(gòu)- 一鍵 monorepo 化」時，我們提到了: 在對原工程做 monorepo 化時，需要對原工程進行“依賴解析”和“代碼引用路徑修正”。其中專門強調(diào)了「基于 AST 或正則」。
圖片
圖片
最開始，我們是基于 Babel 的 AST 解析能力，對工程做「依賴解析和代碼轉(zhuǎn)換」的。
但實踐過程中發(fā)現(xiàn)了 2 個問題：
速度慢
對于效率工程的大型中后臺應(yīng)用，代碼規(guī)模是龐大的，基于 Babel 做一次 AST 解析，尤其是再配合外部封裝的 DFS 類算法框架，進行一次全量解析的耗時有時會持續(xù) 10min 以上，這和我們原來的期待（30s 以內(nèi)）是不相符的。
最初，我們只是對外部封裝的 DFS 類算法框架做了時間復(fù)雜度上的優(yōu)化（如加緩存、轉(zhuǎn)為 BFS 可中斷的方式等），效果并不明顯，根源還是 Babel 的 AST 解析性能瓶頸。
不正確的新代碼
對源碼做 AST 插件中的節(jié)點修改后，生成的新代碼，會修改額外的代碼，比如 ts 類型聲明
比如，源碼中的：
const stringList: string[] = []const stringList：any[] = []原因也基本明確，Babel 的插件配置不夠合理，但調(diào)整成本還是很高的，我們對各類配置進行過嘗試，不是很理想。
最終，我們選擇了看起來最笨拙，卻是性能最好的辦法--“正則匹配字符串”來幫助進行依賴解析。
這是部分代碼截圖（正則是用 GPT 生成的，很棒，輔以人工檢查即可）。
圖片
團隊鍛煉
這部分其實是團隊管理和項目管理部分了，如果推進人是比較資深的同學(xué)是能很快地完成中大型項目的核心難點工作的，但也有不少同學(xué)有成長的意愿以及完成挑戰(zhàn)的能力。
那負責(zé)推進的同學(xué)，就要學(xué)會拆解、放手，讓有意愿有潛力的同學(xué)多多承擔(dān)重要工作，同時把控風(fēng)險，保證項目的順利推進。
很榮幸，這個項目在推進的 3 個月內(nèi)，涌現(xiàn)了多位成長明顯的同學(xué)，在整個項目高質(zhì)量完成的結(jié)果上，貢獻了自己的力量，而且很多問題的發(fā)現(xiàn)、解決、通用化方案輸出是這些同學(xué)主動推動的。
推進能力模型
值得思考的是，以效率前端微應(yīng)用推進為例，成功推進一個中大型項目，需要具備怎樣的能力和工作方式？
下圖能力模型是我比較喜歡參考的：
圖片
基于這個能力模型，衍生出的比如：主動性、技術(shù)儲備、任務(wù)分解等各類能力都是可以納入這個模型參考的。
以下是上述能力模型在具體事務(wù)上的工作技巧實踐：
- 閉環(huán)式推進
- 工作四象限
七、技術(shù)之外
本文介紹的技術(shù)方案，是效率前端微應(yīng)用推進的初期設(shè)計的，推進 3 個月以來，中途經(jīng)歷了各種各樣的困難，也有額外的技術(shù)小項被納入微應(yīng)用推進方案，但整體的方向沒有大的變化。
除了技術(shù)方面，我有個心得：“推進的同學(xué)，需要有良好的心理素質(zhì)，并能為自己尋找資源”。
良好的心理素質(zhì)
「Everything is under control」，我想這是設(shè)計技術(shù)方案的同學(xué)需要慢慢具備的心理素質(zhì)。
在推進過程中，你對遇到的困難是否有心理準備？比如技術(shù)方案被挑戰(zhàn)、研發(fā)體驗變化帶來的反彈、回滾難度是否都考慮過。“出現(xiàn)各類問題是很正常的”，是我在推進任何項目都有的心理準備。
為自己尋找資源
在各方對推進項目價值沒有太大異議的前提下，推進的同學(xué)需要假設(shè)任何人包括 Leader 對你需要的幫助是完全不了解的，此時，你需要作為需求方向各個具備資源或者能夠調(diào)動資源的人尋求合理的幫助。
八、后續(xù)：深水區(qū)之前端微服務(wù)化
本文從背景出發(fā)，詳細介紹了效率前端微應(yīng)用推進初期設(shè)定的技術(shù)方案。在推進的 3 個月中，除了完成上述工作外，有多個很重要的技術(shù)小項、人員陸續(xù)加入。
在下一階段，得物效率前端微應(yīng)用的推進將重點關(guān)注業(yè)務(wù)微服務(wù)化能力的建設(shè)。
微服務(wù)化在后端領(lǐng)域已經(jīng)講了很久，在前端領(lǐng)域通常大家提到的是微前端，但本文中提到的「前端微服務(wù)化」更側(cè)重業(yè)務(wù)的多端投放能力。
比如，某個中后臺應(yīng)用的報表能力很強，在其他平臺上，想接入這些報表的話，有幾個方式可以做：
- 該中后臺應(yīng)用做對外投放能力改造，成本與該應(yīng)用本身復(fù)雜度相關(guān)，投放后，方案不具備通用性
- 該中后臺應(yīng)用采用微服務(wù)化能力提升，提升成本極低（比如引入一個微服務(wù)化增強腳本即可），子頁面中的報表即可獨立投放到其他平臺
后續(xù)要推進的即是第二個方案類似的方向，這是部分實現(xiàn)思路：
圖片
在業(yè)務(wù)場景中，如果能夠做到「布局 與 內(nèi)容」的松耦合，對于業(yè)務(wù)本身的多場景接入大有益處，這也是「微應(yīng)用」推進面臨的一個深水區(qū)，值得重度投入，后續(xù)有不錯進展的話，我們會及時分享。
