一、背景

效率工程

隨著業(yè)務(wù)的發(fā)展，組織規(guī)模的擴(kuò)大，越來越多的企業(yè)開始意識到協(xié)作效率對于企業(yè)團(tuán)隊(duì)的重要性，甚至是決定其在某個行業(yè)競爭中突圍的關(guān)鍵，是企業(yè)長久生存的根本。

得物效率工程運(yùn)用產(chǎn)品、技術(shù)、數(shù)據(jù)等手段，全面提升公司的效率。在管理效率、協(xié)同效率、跨團(tuán)隊(duì)溝通效率、產(chǎn)研協(xié)作效率、辦公效率等各方面持續(xù)探索，高效驅(qū)動公司發(fā)展。

效率工程的業(yè)務(wù)場景

上面提到，效率工程為提升企業(yè)協(xié)作效率而生，因此會面臨大量中后臺應(yīng)用場景。

這些中后臺應(yīng)用體現(xiàn)為「PC 站點(diǎn)、H5 站點(diǎn)、飛書應(yīng)用、特定機(jī)器環(huán)境」等，面向所有內(nèi)部員工和部分外部用戶。

在面向多類型用戶和使用場景等條件下，效率工程技術(shù)產(chǎn)品在穩(wěn)定性、體驗(yàn)、擴(kuò)展性等方面面臨的挑戰(zhàn)非常多。

效率工程面臨的問題

效率工程主要的業(yè)務(wù)形態(tài)是「PC 站點(diǎn)的大型中后臺應(yīng)用」，此類應(yīng)用的布局大多數(shù)是這樣的：

圖片

針對這類場景，有此類產(chǎn)品研發(fā)經(jīng)驗(yàn)的同學(xué)，對其面對的問題也會比較熟悉：

1. 依賴管理方面。非 monorepo 類倉庫下，對于只有一個 package.json 對依賴管理，底層依賴如 antd 等版本升級困難，因?yàn)榛貧w成本很高。

      a.個別底層依賴的升級是難以避免的，尤其是涉及穩(wěn)定性、可維護(hù)性、用戶體驗(yàn)方面，在某個節(jié)點(diǎn)會爆發(fā)問題影響線上

2. 代碼耦合度方面。微前端下，如果沒有做好抽象，基座和子應(yīng)用的代碼耦合度容易偏高。
3. 基座通常包括：Layout、權(quán)限控制等通用模塊難免的，在基座中可能包括對特定頁面的處理邏輯，這里不再舉例
4. 業(yè)務(wù)投放成本方面。有些業(yè)務(wù)的內(nèi)容區(qū)非常適合投放到多個平臺，但通常情況下中后臺應(yīng)用代碼的布局和內(nèi)容部分是強(qiáng)耦合的。單獨(dú)將內(nèi)容區(qū)域投放到外部平臺，要一個個處理，成本很高。
5. 比如某個重報(bào)表類平臺，其報(bào)表展示能力能否應(yīng)用在更多平臺上，其投放能力是最重要的影響因素

經(jīng)過調(diào)研后，我們引入微應(yīng)用來解決目前遇到的問題：

微應(yīng)用

一個基于“monorepo & 微前端 & 基座與業(yè)務(wù)分離”的、包括“文檔 & 工具”的一套體系化降低研發(fā)成本和提升用戶體驗(yàn)的技術(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)用」推進(jìn)的項(xiàng)目。

圖片

依賴管理方面

學(xué)習(xí)平臺原來是非 monorepo 結(jié)構(gòu)，只用一個 package.json 做依賴管理，底層依賴 antd 等的版本極難更新，很難享受到最新版本的快樂。

代碼耦合度方面

學(xué)習(xí)平臺 Layout 和各個頁面內(nèi)容部分代碼是強(qiáng)耦合的，Layout 中也有部分頁面的業(yè)務(wù)邏輯。

業(yè)務(wù)投放成本方面

學(xué)習(xí)平臺的多個頁面對外投放是整體性投放，需要對 Layout 做特殊處理、權(quán)限特殊處理等方式處理后，才能開始投放，投放成本高，而且投放方案不通用。

二、問題分析

Why：為什么做？為什么這樣做？

1. 中后臺應(yīng)用越來越臃腫已成為共識
2. 中后臺需要在功能越來越多的情況下，輕量化地迭代
3. monorepo 配合微前端，是中后臺應(yīng)用輕量化迭代的有效方案

Who: 用戶是誰？

1. 業(yè)務(wù)前端：能夠快速理解遷移方案、低成本使用配套工具完成遷移、有充分的 Q/A 文檔介紹
2. Leader：能夠通過看板等產(chǎn)品、結(jié)合指標(biāo)，快速判斷遷移后的工程質(zhì)量，在長期維護(hù)狀態(tài)下保證工程質(zhì)量不快速下降

What：做什么？

1. 最佳實(shí)踐文檔：面向業(yè)務(wù)前端，要求通俗易懂，業(yè)務(wù)前端可以在 0.5D 內(nèi)快速理解整個方案
2. 遷移工具：提供一個工具，幫助開發(fā)者快速完成遷移
3. 巡檢看板：查看各類指標(biāo)，如依賴版本是否過期、公共模塊位置是否合理等

When：什么時候做？

1. 一個中后臺項(xiàng)目子應(yīng)用超過 X 個，感官越來越臃腫的情況下，可以考慮做微應(yīng)用化了
2. 想在中后臺項(xiàng)目前期打好基礎(chǔ)，便于后續(xù)迭代提效，可以考慮使用微應(yīng)用了

Where：在哪里做？

1. 解釋：很顯然這不是在說物理位置，在研發(fā)流程中，這個工具該處于什么位置
2. 遷移中：在業(yè)務(wù)開發(fā)者本機(jī)執(zhí)行遷移動作、飛書文檔完成背景介紹
3. 遷移后：有在線的巡檢平臺可以：執(zhí)行巡檢、查看巡檢報(bào)告

How：如何做？

1. 要同時進(jìn)行 monorepo 化和微前端化，工作量大、操作復(fù)雜、穩(wěn)定性保障難度大
2. 第 1 步：以 1 個項(xiàng)目試點(diǎn)，跑通流程、輸出“最佳實(shí)踐（初版）”、輸出“遷移工具（初版）”
3. 第 2 步：以 1 個項(xiàng)目驗(yàn)證全套方案，輸出“最佳實(shí)踐（修正版）”、輸出“遷移工具（修正版）”
4. 第 3 步：以 1 個項(xiàng)目完成全套方案，輸出“最佳實(shí)踐（完整版）”、輸出“遷移工具（完整版）”
5. 第 4 步：更多項(xiàng)目接入

三、明確目標(biāo)

根據(jù) SMART 原則，我們制定了如下目標(biāo)（時間限制在 3 個月內(nèi)）：

1. 降低微應(yīng)用化遷移成本，中大型應(yīng)用的微應(yīng)用化遷移耗時降低 30%

耗時降低計(jì)算公式：1 - (有 SOP 時微應(yīng)用化遷移估時 / 無 SOP 時微應(yīng)用化遷移估時)

2. 降低學(xué)習(xí)平臺維護(hù)成本，管理端和學(xué)員端公共依賴升級時的測試耗時降低 50%

耗時降低計(jì)算公式：1 - (微應(yīng)用化后的測試估時 / 微應(yīng)用化前的測試估時)

四、推進(jìn)方案

經(jīng)過以上分析，我們的推進(jìn)方案在「輸出、里程碑、技術(shù)架構(gòu)、測試方案、效果預(yù)估」等方面進(jìn)行了確認(rèn)。

輸出

 1. 面向業(yè)務(wù)開發(fā)者

    a.《效率前端微應(yīng)用最佳實(shí)踐》文檔：幫助業(yè)務(wù)開發(fā)者可以在 0.5D 理解遷移所需的各類背景

    b.「微應(yīng)用遷移技術(shù)產(chǎn)品 monopower」：幫助業(yè)務(wù)開發(fā)者完成應(yīng)用 monorepo 化過程 90% 的工作量

 2. 面向 Leader

    a.「在線巡檢能力和報(bào)告」：幫助 Leader 查看項(xiàng)目完成微應(yīng)用遷移后，工程質(zhì)量是如何的，這里包括了一系列的指標(biāo)

里程碑

圖片

如上圖，里程碑整體分為 2 個階段：

第一階段，通過業(yè)務(wù)的少量落地完成方案驗(yàn)證，側(cè)重在驗(yàn)證

第 1 步：以 1 個項(xiàng)目試點(diǎn)，跑通流程、輸出“最佳實(shí)踐（初版）”、輸出“遷移工具（初版）”，落地 1 ~ 2 個頁面

第 2 步：以 1 個項(xiàng)目驗(yàn)證全套方案，輸出“最佳實(shí)踐（修正版）”、輸出“遷移工具（修正版）”，落地 3 ~ 10 個頁面

第二階段，業(yè)務(wù)全量遷移，側(cè)重在業(yè)務(wù)落地

以 1 個項(xiàng)目完成全套方案，輸出“最佳實(shí)踐（完整版）”、輸出“遷移工具（完整版）”，落地該應(yīng)用全部頁面

技術(shù)架構(gòu)

1. 迪米特法則

即最小知識原則，在 SOLID 設(shè)計(jì)原則中符合 「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)缺點(diǎn)，是否滿足業(yè)務(wù)需求

閉環(huán)：當(dāng)項(xiàng)目進(jìn)行微應(yīng)用化后，定時巡檢和告警會觸發(fā)運(yùn)行，定期掃描工程質(zhì)量并通知到相關(guān)方

2. 整體架構(gòu)

圖中綠色區(qū)域是需要開發(fā)的產(chǎn)品或文檔。

圖片

整體架構(gòu)包括以下核心模塊：

    a.新增微應(yīng)用倉庫

        不在老倉庫進(jìn)行微應(yīng)用化改造，保證穩(wěn)定性。

    b.monopower cli/server

        i.一鍵改造非 monorepo 項(xiàng)目為 monorepo 項(xiàng)目

圖片

        ii.掃描項(xiàng)目質(zhì)量，并輸出報(bào)告和告警

圖片

    c.微應(yīng)用遷移最佳實(shí)踐文檔

3. 一鍵 monorepo 化

轉(zhuǎn)換過程

1. 對原工程做「基于 AST 或正則」的依賴分析
2. 調(diào)整目錄結(jié)構(gòu)為 monorepo
3. 對新工程中代碼做「基于 AST 或正則」的引用路徑修正

比如，原工程中有 import utils from '@/utils'，新工程可能需要變?yōu)?import utils from '@monorepo/utils'

圖片

技術(shù)實(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 個頁面進(jìn)行微應(yīng)用化。

那么，A 頁面上線后，假如第二個迭代，原倉庫依然需要對  A 頁面修改，就意味著，第二個迭代要同時上線 A/B 頁面。

為了減少回歸測試成本，我們用 monopower transfer 做了一個轉(zhuǎn)換后的 diff 展示，如果 A 頁面在兩次迭代被進(jìn)行了兩次 transfer，且 diff 沒有變化，就不需要回歸測試。

測試方案

1. 兩個方案

    a. 以單個路由為粒度，每次全量切換該路由的流量到微應(yīng)用版本    b. 以整個工程為粒度，按照人群/流量分布為維度，定向灰度到微應(yīng)用版本

2. 選定方案

最終我們用第一個測試方案。原因如下：

    a. 學(xué)習(xí)平臺是微應(yīng)用推進(jìn)的第一個驗(yàn)證型項(xiàng)目，短時間內(nèi)全量完成改造的難度太大

    b. 以單個路由為粒度，能夠逐步修復(fù)問題，驗(yàn)證整體方案的可行性

3. 應(yīng)用效果

使用第一個方案，在整個微應(yīng)用落地過程中是比較順利的，平穩(wěn)地將近 40 個頁面逐批次切換到微應(yīng)用模式。

這里也頻繁用到了「推進(jìn)方案 -- 技術(shù)架構(gòu)  -- 一鍵 monorepo 化」中提到的“多次 monorepo 化”，利用 monopower transfer 的 diff 結(jié)果，來減少回歸測試成本。

效果評估

1. 學(xué)習(xí)平臺改造前后的工程結(jié)構(gòu)對比

改造前：

圖片

改造后：

圖片

2. 遷移前

系統(tǒng)自檢：

圖片

3. 遷移中

遷移步驟：

    i.安裝命令行 monopower

    ii.在當(dāng)前項(xiàng)目執(zhí)行 monopower transfer，執(zhí)行 monorepo 化

    iii.逐個頁面測試

圖片

正向依賴分析：

比如入口文件 index.tsx，可以基于該入口文件做依賴樹的可視化分析

圖片

反向依賴分析：

用于分析某個文件被哪些文件引用，用于分析該文件的重要性等

圖片

4. 遷移后

定期巡檢，輸出巡檢報(bào)告，包括且不限于「工程化配置、代碼質(zhì)量、公共依賴引用、依賴收斂、穩(wěn)定性、性能、用戶體驗(yàn)」等分析結(jié)果。

巡檢工具內(nèi)部，可以結(jié)合靜態(tài)文件掃描和運(yùn)行時模擬，對當(dāng)前項(xiàng)目做全方位掃描，當(dāng)然側(cè)重在微應(yīng)用方面的健康度。

五、目標(biāo)達(dá)成情況

上文中提到了「微應(yīng)用」推進(jìn)的目標(biāo)，這里分開演示效果。

目標(biāo) 1：降低微應(yīng)用化遷移成本，中大型的微應(yīng)用化遷移耗時降低 30%

耗時降低計(jì)算公式：1 - (有 SOP 時微應(yīng)用化遷移估時 / 無 SOP 時微應(yīng)用化遷移估時)

改造前

圖片

用 monopower transfer 對學(xué)習(xí)平臺進(jìn)行 monorepo 化改造：

圖片

圖片

改造后

圖片

目標(biāo) 2：降低學(xué)習(xí)平臺維護(hù)成本，管理端和學(xué)員端公共依賴升級時的測試耗時降低 50%

耗時降低計(jì)算公式：1 - (微應(yīng)用化后的測試估時 / 微應(yīng)用化前的測試估時)

很顯然，這是利用了 monorepo 類工程的天然優(yōu)勢：依賴隔離。

圖片

學(xué)習(xí)平臺可以針對管理端和學(xué)員端做依賴隔離，從而可以單獨(dú)升級學(xué)員端、管理端業(yè)務(wù)的底層依賴。

六、推進(jìn)的經(jīng)驗(yàn)教訓(xùn)

變與不變

上述推進(jìn)方案確認(rèn)后，剩下的就是根據(jù)各個里程碑完成對應(yīng)進(jìn)度即可，因此在推進(jìn)過程中，沒有遇到「進(jìn)度」方面的問題。

當(dāng)然在推進(jìn)途中，隨時會面臨實(shí)際的技術(shù)問題、人員調(diào)整、業(yè)務(wù)壓力等，除了保持足夠的心理準(zhǔn)備外，在“技術(shù)調(diào)研”階段，為關(guān)鍵鏈路做好多個方案對比和意外狀況的預(yù)案尤為重要。

比如，在微前端選型中，社區(qū)中有諸多方案可選（iframe / qiankun / wujie / micro-app 等），在初期擬定某個微前端方案后，如果中途遇到難以解決的問題，就需要及時復(fù)盤、調(diào)整到備選方案。

備選方案也要做足功課，這是我們在推進(jìn)微應(yīng)用落地過程中的重要經(jīng)驗(yàn)

Babel在實(shí)際應(yīng)用中的劣勢

在上文介紹「推進(jìn)方案 - 技術(shù)架構(gòu)- 一鍵 monorepo 化」時，我們提到了: 在對原工程做 monorepo 化時，需要對原工程進(jìn)行“依賴解析”和“代碼引用路徑修正”。其中專門強(qiáng)調(diào)了「基于 AST 或正則」。

圖片

圖片

最開始，我們是基于 Babel 的 AST 解析能力，對工程做「依賴解析和代碼轉(zhuǎn)換」的。

但實(shí)踐過程中發(fā)現(xiàn)了 2 個問題：

速度慢

對于效率工程的大型中后臺應(yīng)用，代碼規(guī)模是龐大的，基于 Babel 做一次 AST 解析，尤其是再配合外部封裝的 DFS 類算法框架，進(jìn)行一次全量解析的耗時有時會持續(xù) 10min 以上，這和我們原來的期待（30s 以內(nèi)）是不相符的。

最初，我們只是對外部封裝的 DFS 類算法框架做了時間復(fù)雜度上的優(yōu)化（如加緩存、轉(zhuǎn)為 BFS 可中斷的方式等），效果并不明顯，根源還是 Babel 的 AST 解析性能瓶頸。

不正確的新代碼

對源碼做 AST 插件中的節(jié)點(diǎn)修改后，生成的新代碼，會修改額外的代碼，比如 ts 類型聲明

比如，源碼中的：

const stringList: string[] = []

const stringList：any[] = []

原因也基本明確，Babel 的插件配置不夠合理，但調(diào)整成本還是很高的，我們對各類配置進(jìn)行過嘗試，不是很理想。

最終，我們選擇了看起來最笨拙，卻是性能最好的辦法--“正則匹配字符串”來幫助進(jìn)行依賴解析。

這是部分代碼截圖（正則是用 GPT 生成的，很棒，輔以人工檢查即可）。

圖片

團(tuán)隊(duì)鍛煉

這部分其實(shí)是團(tuán)隊(duì)管理和項(xiàng)目管理部分了，如果推進(jìn)人是比較資深的同學(xué)是能很快地完成中大型項(xiàng)目的核心難點(diǎn)工作的，但也有不少同學(xué)有成長的意愿以及完成挑戰(zhàn)的能力。

那負(fù)責(zé)推進(jìn)的同學(xué)，就要學(xué)會拆解、放手，讓有意愿有潛力的同學(xué)多多承擔(dān)重要工作，同時把控風(fēng)險(xiǎn)，保證項(xiàng)目的順利推進(jìn)。

很榮幸，這個項(xiàng)目在推進(jìn)的 3 個月內(nèi)，涌現(xiàn)了多位成長明顯的同學(xué)，在整個項(xiàng)目高質(zhì)量完成的結(jié)果上，貢獻(xiàn)了自己的力量，而且很多問題的發(fā)現(xiàn)、解決、通用化方案輸出是這些同學(xué)主動推動的。

推進(jìn)能力模型

值得思考的是，以效率前端微應(yīng)用推進(jìn)為例，成功推進(jìn)一個中大型項(xiàng)目，需要具備怎樣的能力和工作方式？

下圖能力模型是我比較喜歡參考的：

圖片

基于這個能力模型，衍生出的比如：主動性、技術(shù)儲備、任務(wù)分解等各類能力都是可以納入這個模型參考的。

以下是上述能力模型在具體事務(wù)上的工作技巧實(shí)踐：

1. 閉環(huán)式推進(jìn)
2. 工作四象限

七、技術(shù)之外

本文介紹的技術(shù)方案，是效率前端微應(yīng)用推進(jìn)的初期設(shè)計(jì)的，推進(jìn) 3 個月以來，中途經(jīng)歷了各種各樣的困難，也有額外的技術(shù)小項(xiàng)被納入微應(yīng)用推進(jìn)方案，但整體的方向沒有大的變化。

除了技術(shù)方面，我有個心得：“推進(jìn)的同學(xué)，需要有良好的心理素質(zhì)，并能為自己尋找資源”。

良好的心理素質(zhì)

「Everything is under control」，我想這是設(shè)計(jì)技術(shù)方案的同學(xué)需要慢慢具備的心理素質(zhì)。

在推進(jìn)過程中，你對遇到的困難是否有心理準(zhǔn)備？比如技術(shù)方案被挑戰(zhàn)、研發(fā)體驗(yàn)變化帶來的反彈、回滾難度是否都考慮過?！俺霈F(xiàn)各類問題是很正常的”，是我在推進(jìn)任何項(xiàng)目都有的心理準(zhǔn)備。

為自己尋找資源

在各方對推進(jìn)項(xiàng)目價(jià)值沒有太大異議的前提下，推進(jìn)的同學(xué)需要假設(shè)任何人包括 Leader 對你需要的幫助是完全不了解的，此時，你需要作為需求方向各個具備資源或者能夠調(diào)動資源的人尋求合理的幫助。

八、后續(xù)：深水區(qū)之前端微服務(wù)化

本文從背景出發(fā)，詳細(xì)介紹了效率前端微應(yīng)用推進(jìn)初期設(shè)定的技術(shù)方案。在推進(jìn)的 3 個月中，除了完成上述工作外，有多個很重要的技術(shù)小項(xiàng)、人員陸續(xù)加入。

在下一階段，得物效率前端微應(yīng)用的推進(jìn)將重點(diǎn)關(guān)注業(yè)務(wù)微服務(wù)化能力的建設(shè)。

微服務(wù)化在后端領(lǐng)域已經(jīng)講了很久，在前端領(lǐng)域通常大家提到的是微前端，但本文中提到的「前端微服務(wù)化」更側(cè)重業(yè)務(wù)的多端投放能力。

比如，某個中后臺應(yīng)用的報(bào)表能力很強(qiáng)，在其他平臺上，想接入這些報(bào)表的話，有幾個方式可以做：

1. 該中后臺應(yīng)用做對外投放能力改造，成本與該應(yīng)用本身復(fù)雜度相關(guān)，投放后，方案不具備通用性
2. 該中后臺應(yīng)用采用微服務(wù)化能力提升，提升成本極低（比如引入一個微服務(wù)化增強(qiáng)腳本即可），子頁面中的報(bào)表即可獨(dú)立投放到其他平臺

后續(xù)要推進(jìn)的即是第二個方案類似的方向，這是部分實(shí)現(xiàn)思路：

圖片

在業(yè)務(wù)場景中，如果能夠做到「布局 與 內(nèi)容」的松耦合，對于業(yè)務(wù)本身的多場景接入大有益處，這也是「微應(yīng)用」推進(jìn)面臨的一個深水區(qū)，值得重度投入，后續(xù)有不錯進(jìn)展的話，我們會及時分享。