美團(tuán)前端研發(fā)框架Rome實(shí)踐和演進(jìn)趨勢(shì)

我們也可以一鍵完成對(duì)應(yīng)的水印接入，同時(shí)開發(fā)配置時(shí)有對(duì)應(yīng)的配置項(xiàng)智能提示。各種開閉能力的屬性命名語(yǔ)義可能沒那么清晰，可以通過(guò)如VSCode中的智能提示一鍵跳轉(zhuǎn)到對(duì)應(yīng)能力的文檔地址，查看它的實(shí)現(xiàn)原理以及使用方法。

2.1.2 降建設(shè)成本

之前組織下建設(shè)的很多能力是偏小蘑菇的形式，“小蘑菇”的語(yǔ)義是整體工程能力的生命周期比較短，會(huì)進(jìn)行頻繁的重復(fù)建設(shè)。但我們希望以一個(gè)大樹的形式建設(shè)，“大樹”的語(yǔ)義是我們可以通過(guò)跨團(tuán)隊(duì)、橫向方式進(jìn)行高質(zhì)量的設(shè)計(jì)和建設(shè)，通過(guò)評(píng)審委員會(huì)把控整體的方案建設(shè)，把方案拆分到幾個(gè)階段，橫向團(tuán)隊(duì)共建，共同完成核心能力，比如Serverless、SSR等。

工程能力生態(tài)

如果大家對(duì)工程框架的建設(shè)能力感興趣，可以參考我們內(nèi)部的效率、質(zhì)量、體驗(yàn)和領(lǐng)域?qū)嵺`進(jìn)行對(duì)應(yīng)分類的建設(shè)。我們通過(guò)一線調(diào)研、能力盤點(diǎn)的方式建設(shè)了31個(gè)，在企業(yè)內(nèi)進(jìn)行建設(shè)時(shí)，有很多能力一開始可能本身成本就很高，比如統(tǒng)一基建接入等，大概需要 30人力/個(gè)，而實(shí)際業(yè)務(wù)需求開發(fā)一共只有幾天時(shí)間，很難說(shuō)服產(chǎn)品運(yùn)營(yíng)單獨(dú)抽出大量人力開發(fā)前端基建能力，這部分我們就以共建+橫向評(píng)審的方式，保證業(yè)務(wù)團(tuán)隊(duì)可以攤平整體的建設(shè)成本。

典型共建案例

Serverless SSR能力，在休娛頻道的密室和優(yōu)選團(tuán)長(zhǎng)端的訂單管理流量分別是百萬(wàn)級(jí)別和千萬(wàn)級(jí)別，整體秒開可以做到90%左右。

整個(gè)過(guò)程是Rome + Arche團(tuán)隊(duì)共建并形成到店標(biāo)準(zhǔn)，業(yè)務(wù)統(tǒng)一落地，過(guò)程中有超過(guò)3個(gè)業(yè)務(wù)團(tuán)隊(duì)參與了部分能力建設(shè)。

這里簡(jiǎn)要介紹下Serverless的方案流程：

首先是訪問(wèn)自動(dòng)降級(jí)，用戶通過(guò)負(fù)載均衡命中對(duì)應(yīng)的網(wǎng)關(guān)，命中對(duì)應(yīng)的Serverless的Node Runtime，這里會(huì)有對(duì)應(yīng)頁(yè)面粒度的SSR渲染函數(shù)，當(dāng)用戶訪問(wèn)服務(wù)器返回 5.x.x 狀態(tài)碼或超時(shí)時(shí)會(huì)自動(dòng)降級(jí)到CSR資源（SPA頁(yè)面）；即使出現(xiàn)了極端情況，比如 SSR 服務(wù)異常，我們也可以保證整體頁(yè)面可用，差別主要在 SSR場(chǎng)景秒開~90%，CSR場(chǎng)景秒開~30%，兼顧了性能和穩(wěn)定性的優(yōu)勢(shì)。

支持自動(dòng)擴(kuò)縮容和流失渲染，對(duì)接公司Nest基建，支持業(yè)務(wù)無(wú)感知的峰值流量自動(dòng)擴(kuò)縮容；同時(shí)長(zhǎng)列表頁(yè)面也可以通過(guò)流式渲染來(lái)降低TTFB時(shí)間。

2.1.3 提研發(fā)效率

編譯提速主要分兩個(gè)方向進(jìn)行業(yè)務(wù)落地，分別是Webpack體系和Vite體系。

編譯提速 - Webpack體系優(yōu)化

首先是Webpack體系，因?yàn)槲覀冋w的技術(shù)棧分Vue和React兩部分，我們會(huì)抽一部分基礎(chǔ)的跨技術(shù)棧的Webpack配置，上層有不同團(tuán)隊(duì)分別維護(hù)Vue技術(shù)棧和React技術(shù)棧的特有配置，中間我們會(huì)進(jìn)行專項(xiàng)優(yōu)化，包括像Webpack5的開發(fā)優(yōu)化、編譯壓縮器、SWC和esbuild等。

另外，我們做工具時(shí)，不僅要考慮我們本身構(gòu)建工具比如Webpack，也要考慮如何和我們的CI/CD平臺(tái)結(jié)合，如緩存復(fù)用結(jié)合依賴安裝、構(gòu)建工具做，在很多需求場(chǎng)景下，可以獲得耗時(shí)的10倍提升，CI/CD側(cè)我們也支持分粒度的構(gòu)建，比如大型MPA做頁(yè)面粒度的構(gòu)建等。

編譯提速- 開發(fā)時(shí)?鍵Vite

Vite主要是我們?cè)陂_發(fā)時(shí)使用的，Webpack是構(gòu)建時(shí)使用，除了少部分增量項(xiàng)目的開發(fā)和構(gòu)建都走Vite，大多數(shù)存量項(xiàng)目都是開發(fā)使用Vite保證效果，構(gòu)建階段使用Webpack。

整體流程：首先是啟動(dòng)，通過(guò)Vite，比如createServer拉起頁(yè)面，抹平Webpack差異；環(huán)境變量的抹平，保證客戶端Webpack存量項(xiàng)目，將Webpack客戶端的環(huán)境變量注入到Vite端；對(duì)配置文件，大家原本在rome.config.js中的Webpack配置也可以一鍵轉(zhuǎn)換為對(duì)應(yīng)的Vite配置；在下層我們會(huì)做內(nèi)置的技術(shù)棧插件，包括Vue2/Vue3 SFC+JSX，包括React的內(nèi)置插件等；比較繁瑣的是生態(tài)兼容，在公司內(nèi)這部分的工作量比較大，像我們的一些SaaS的靜態(tài)資源的一些路徑等，包括之前我們存量Webpack這么多年積累下來(lái)的公司基建，我們?nèi)绾伪ＷC它能被注入到Vite端，包括組件庫(kù)按需引入，當(dāng)一些模塊比如common.js的模塊如何指向?qū)?yīng)的esmodule目錄等，最后我們會(huì)屏蔽一些認(rèn)知成本，把Vue、React和公司依賴包內(nèi)置到Vite預(yù)編譯內(nèi)容中。

依賴提速

主要分兩部分，分別是開發(fā)階段和部署階段。

首先會(huì)做工程框架自身Node.js依賴的預(yù)構(gòu)建，這部分核心解決的是Node.js端公司內(nèi)外包資源的體積和遞歸依賴數(shù)量龐大的問(wèn)題。依賴安裝的一個(gè)核心耗時(shí)其實(shí)是遞歸依賴龐雜，需要逐個(gè)安裝帶來(lái)的耗時(shí)，比如需要安裝A，其實(shí)A依賴了B、C、D、E、F、G，整體安裝耗時(shí)就會(huì)非常久，同時(shí)研發(fā)同學(xué)對(duì)Node.js包體積、依賴數(shù)量一般不如面向?yàn)g覽器端投放的NPM包那么敏感，這個(gè)時(shí)候預(yù)編譯就很關(guān)鍵。

其次是把整體的依賴環(huán)節(jié)包管理工具切換到Pnpm。這部分經(jīng)過(guò)調(diào)研（Pnpm、Yarn Berry、Yarn Berry with PNP等），判斷Pnpm是未來(lái)幾年的核心趨勢(shì)，同時(shí)可以穩(wěn)定發(fā)展。內(nèi)部建設(shè)了對(duì)應(yīng)的包管理遷移工具，來(lái)服務(wù)企業(yè)內(nèi)幾百個(gè)、上千個(gè)項(xiàng)目。

在部署階段定制了Rome依賴安裝Docker鏡像，鎖Pnpm版本和內(nèi)置常用依賴、緩存復(fù)用，它的整體邏輯是上一次需求迭代和下一次需求迭代可能依賴包的變化沒有那么多。我們?cè)诘诙伟l(fā)布的時(shí)候，如果能夠嘗試命中上一次的node_modules里的一些包，那第二次安裝耗時(shí)就會(huì)有一個(gè)比較大的提升。

| 2.2 演變路徑

第一階段的時(shí)候是強(qiáng)依賴Webpack和Vue技術(shù)棧的。直到2020年-2021年，像社區(qū)UI框架有Solid.js、Svelte、Vue3，構(gòu)建工具有Esbuild、Rspack、Vite等且發(fā)展勢(shì)頭也比較好，面向這個(gè)大趨勢(shì)，我們希望研發(fā)框架能夠分層過(guò)渡，不再和具體的UI框架、構(gòu)建工具綁定：

1. 首先最底層是差異機(jī)制，核心做插件的加載和調(diào)度；
2. 中間層是構(gòu)建工具的bundler ，這一層主要是分別結(jié)合Webpack、esbuild、Rspack等構(gòu)建實(shí)現(xiàn)，支持大量項(xiàng)目；
3. 上層Plugin、Preset做框架拓展，各個(gè)業(yè)務(wù)能夠基于場(chǎng)景定制自己的工程能力；
4. 頂層是品牌指令（ bin ），這部分主要是企業(yè)內(nèi)合作時(shí)業(yè)務(wù)方希望保持自己的品牌名。

示例如下圖右側(cè)，大多數(shù)情況下，我們有一個(gè)新的研發(fā)框架出來(lái)，只需要開發(fā)我們對(duì)應(yīng)的語(yǔ)言特色的插件集合就行，底層插件機(jī)制+構(gòu)建工具大家其實(shí)可以保持一致的。

| 2.3 規(guī)?；?jí)

框架價(jià)值=覆蓋范圍 * 功能價(jià)值。我們的共識(shí)是建設(shè)的能力需要落地才能產(chǎn)生價(jià)值，核心是幫助大家業(yè)務(wù)低成本地享受好用的能力。

如下圖所示，是某個(gè)業(yè)務(wù)的升級(jí)成本圖，可以看到有100多個(gè)項(xiàng)目（成本均值~5pd/項(xiàng)目），業(yè)務(wù)面臨幾百天的成本。對(duì)團(tuán)隊(duì)Tech Lead很難說(shuō)服業(yè)務(wù)產(chǎn)品運(yùn)營(yíng)業(yè)務(wù)階段投入升級(jí)。對(duì)一線同學(xué)來(lái)說(shuō)，雖然能力很多、很棒，但是升級(jí)風(fēng)險(xiǎn)怎么處理：編譯提升10s，線上問(wèn)題定位消耗一周。

這部分的我們給兩個(gè)解決方案。

首先是提供遷移工具（非Rome到Rome項(xiàng)目）：

1. 巨石項(xiàng)目做存量遷移時(shí)，一般同學(xué)下意識(shí)反應(yīng)是通過(guò)Babel做靜態(tài)解析遷移，純靜態(tài)解析實(shí)測(cè)的遷移準(zhǔn)確率在40%，也就說(shuō)一個(gè)項(xiàng)目40%的事情通過(guò)Babel可以搞定。
2. 第二階段是基于構(gòu)建工具的依賴引用關(guān)系去做遷移，通過(guò)構(gòu)建工具啟動(dòng)時(shí)的模塊工廠鉤子去生成依賴引用樹狀結(jié)構(gòu)然后做遷移，得到遷移準(zhǔn)確率在60%左右。
3. 第三階段是動(dòng)態(tài)分析結(jié)合AST靜態(tài)分析一起去做，在數(shù)據(jù)采集階段通過(guò)構(gòu)建工具的模塊工廠鉤子、Vue/React實(shí)例化對(duì)象的路由/數(shù)據(jù)流配置去生成依賴圖結(jié)構(gòu)，通過(guò)recast等工具進(jìn)行靜態(tài)解析，不用Babel是因?yàn)閞ecast有比較好保持樣式的代碼回寫，文件內(nèi)容增刪改后寫回原文件樣式不亂，同學(xué)在git diff時(shí)需要Code Review代碼就可以少一些，便于遷移影響范圍判斷。

4. 最后配備上基礎(chǔ)公司基建做的一些依賴版本、體積、兼容性檢測(cè)的質(zhì)量工具，自動(dòng)遷移了差不多有100多個(gè)項(xiàng)目，線上零Case。

另一個(gè)是做框架生態(tài)的大版本升級(jí)，假如一個(gè)季度推出來(lái)一個(gè)大版本，實(shí)際業(yè)務(wù)開發(fā)升級(jí)難度、成本就會(huì)比較大，業(yè)務(wù)可能也不敢升級(jí)，這時(shí)大版本升級(jí)就要提供關(guān)鍵流程自動(dòng)遷移支持：

1. 當(dāng)從Yarn到Pnpm的時(shí)候，會(huì)做幽靈依賴檢測(cè)，自動(dòng)向Pnpm/src的幽靈依賴配置等；
2. 也會(huì)做工程源碼對(duì)比；
3. 構(gòu)建配置，如Webpack前后框架無(wú)關(guān)的配置對(duì)比；
4. 產(chǎn)物變動(dòng)升級(jí)前后entry數(shù)量是否不一樣、產(chǎn)物有沒有明顯變大；
5. 兼容性檢測(cè)，升級(jí)前是ES 5+的代碼，升級(jí)后到ES 6了，那也會(huì)出問(wèn)題；
6. 線上驗(yàn)證等。

3 框架開發(fā)輔助

我們Rome的工程開發(fā)輔助工具是基于IDE的。一般業(yè)界的開發(fā)輔助工具兩種形式，下圖是Vue UI和VSCode的拓展圖示：

• 一是通過(guò)Web實(shí)現(xiàn)，典型案例有Vue UI/Umi UI/Angular Console等；
• 二是VSCode拓展，如Ice Works等。

| 3.1 為什么要基于IDE？

理解：對(duì)于Web形式，業(yè)界以Umi UI（更先進(jìn)）和Vue CLI為主，雖然它們都是基于Web實(shí)現(xiàn)，但出發(fā)點(diǎn)不太一樣，Vue UI核心是做體驗(yàn)提升，支持工程創(chuàng)建CLI可視化，工程配置分析等；但是UMI UI要服務(wù)公司內(nèi)部，更多的是做提效，支持一些組的資產(chǎn)插入、執(zhí)行工程任務(wù)比如build/lint等。

基于Web做開發(fā)輔助工具

• 好處：跨IDE的成本比較低，前端同學(xué)覆蓋會(huì)比較全，也可以解決IDE內(nèi)功能交互UI受限問(wèn)題。
• 問(wèn)題：VSCode不開放這部分的UI侵入能力，一方面心智認(rèn)知類Umi UI的趨勢(shì)其實(shí)把開發(fā)時(shí)的用戶心智切換到Web端。但我們研發(fā)時(shí)，其實(shí)要在IDE看代碼、理解代碼、寫代碼，當(dāng)我們熱更新起來(lái)以后，像構(gòu)建、物料插入、Link等其實(shí)比較低頻，就會(huì)帶來(lái)一個(gè)問(wèn)題，我們研發(fā)時(shí)的心智很難切到對(duì)應(yīng)的瀏覽器端。另一方面研發(fā)鏈路，長(zhǎng)期來(lái)看，不管是業(yè)界還是美團(tuán)內(nèi)部的研發(fā)趨勢(shì)中就一部分場(chǎng)景，后續(xù)肯定是用Cloud IDE，但是我們工程框架的Web端這種開發(fā)輔助工具，如果通過(guò)Web形式實(shí)現(xiàn)，就很難融入到我們的研發(fā)鏈路中。

IDE側(cè)方案確實(shí)存在UI交互受限、視窗面積、跨IDE開發(fā)成本等問(wèn)題，因?yàn)橥瑢W(xué)在開發(fā)時(shí)，VSCode的面積就這么大，每彈出一個(gè)Webview就會(huì)侵占用戶的開發(fā)視窗，會(huì)比較難受。

選型原因：

• 用戶頻次：我們核心是企業(yè)內(nèi)做提效，那就決定了繞不開IDE側(cè)，而且TA是用戶高頻部分，而且我們?cè)诖a側(cè)也可以復(fù)用VSCode、IDE側(cè)的LS API，交互受限通過(guò)用戶引導(dǎo)是可以接受的。
• 研發(fā)整合：我們后續(xù)可以在Cloud IDE整體比較成熟的時(shí)候，會(huì)把部分輕量迭代切換到Cloud IDE中進(jìn)行研發(fā)，同時(shí)希望新模式下開發(fā)輔助工具可以繼續(xù)產(chǎn)生價(jià)值。第二是可以在IDE側(cè)整合上下游鏈路，保證用戶心智可以一直停留在IDE內(nèi)而不用跨平臺(tái)操作，整體成本可能會(huì)比較高。

• 快速落地：不管是Vue UI這種全局CLI的形式，還是Umi UI這種跟隨項(xiàng)目的NPM包形式，都有一個(gè)比較大的問(wèn)題是版本碎片化，我們整體Node的生態(tài)社區(qū)，NPM包版本的不穩(wěn)定性，對(duì)同學(xué)來(lái)說(shuō)是認(rèn)知比較強(qiáng)烈的一個(gè)事，功能迭代后，讓大家進(jìn)行NPM包版本升級(jí)難度會(huì)比較大，而且同學(xué)會(huì)比較慌，而VSCode IDE側(cè)的進(jìn)行發(fā)布，它是可以進(jìn)行動(dòng)態(tài)版本下發(fā)的，保證我們大范圍落地，這一部分的兼容成本就由我們框架團(tuán)隊(duì)內(nèi)部消化，做一些兼容。

| 3.2 提效率

提效率的一個(gè)例子是“一分鐘內(nèi)部署”，這里主要解決我們高頻的測(cè)試環(huán)境部署流程冗長(zhǎng)問(wèn)題。2021年我們Rome?線上環(huán)境發(fā)布?概10W次/年，核?流程369s/次，如下圖所示：

通過(guò)我們的開發(fā)輔助工具，可以做到頁(yè)面粒度的CSR/SSR發(fā)布，同學(xué)不需要關(guān)注跨平臺(tái)之間有哪些工作量，我們會(huì)在背后同步并且流轉(zhuǎn)DevOps節(jié)點(diǎn)，把原本我們要在研發(fā)流程中，企業(yè)內(nèi)要做質(zhì)量分析、規(guī)范卡控等部分做異步，然后異步進(jìn)行觸發(fā)，整體的鏈路就可以保證一分鐘內(nèi)完成部署。

| 3.3 提質(zhì)量

IDE可以做開發(fā)時(shí)質(zhì)量檢測(cè)，開發(fā)時(shí)會(huì)有歷史的線上故障提醒。

哪些問(wèn)題我們之前已經(jīng)出過(guò)很多次線上故障了，在開發(fā)時(shí)就會(huì)實(shí)時(shí)檢測(cè)代碼并提示這部分應(yīng)該進(jìn)行修復(fù)，否則后續(xù)可能會(huì)出現(xiàn)線上故障。

它和ESLint的區(qū)別：

1. 首先是我們可以做規(guī)則的動(dòng)態(tài)下發(fā)，研發(fā)規(guī)則配置，做管理中心化；
2. 內(nèi)容上我們也會(huì)支持故障包版本，比如業(yè)界之前出過(guò)幾次故障包問(wèn)題，包括core-js、內(nèi)部組件庫(kù)故障版本等；
3. 我們也會(huì)把歷史業(yè)務(wù)線上故障分析出來(lái)并提示，點(diǎn)擊鏈接就可以跳轉(zhuǎn)詳細(xì)查看之前具體是出了哪次線上問(wèn)題，是由什么引起的。

| 3.4 平臺(tái)流轉(zhuǎn)

我們內(nèi)部研發(fā)時(shí)不僅要開發(fā)，還有設(shè)計(jì)稿，包括DevOps平臺(tái)的流轉(zhuǎn)等，也會(huì)上下游聯(lián)動(dòng)，保證設(shè)計(jì)可以快速到DevOps平臺(tái)，DevOps平臺(tái)可以一鍵打開本地VS Code，記憶歷史的倉(cāng)庫(kù)和分支并快速打開，也可以快速流轉(zhuǎn)到設(shè)計(jì)平臺(tái)，開發(fā)完返回剩余流程。

| 3.5 文檔提示

開發(fā)時(shí)也會(huì)給到大家文檔提示，只要研發(fā)人員托管到到店內(nèi)部的知識(shí)庫(kù)，就可以在開發(fā)時(shí)，自動(dòng)進(jìn)行相關(guān)文檔的匹配和跳轉(zhuǎn)提示。

| 3.6 CloudIDE對(duì)接

得益于業(yè)界IDE標(biāo)準(zhǔn)的高度統(tǒng)一，一般CloudIDE僅需一次開發(fā)，即可本地、云端IDE自動(dòng)安裝開發(fā)輔助，能力完全一致。

4 框架度量和業(yè)務(wù)實(shí)踐

| 4.1 框架度量-核心問(wèn)題

問(wèn)題和指標(biāo)

在業(yè)務(wù)規(guī)模不斷擴(kuò)大、能力落地覆蓋范圍及用戶數(shù)量都在不斷增加的背景下，框架現(xiàn)狀衡量、框架如何發(fā)展等問(wèn)題逐漸顯現(xiàn)：

Rome的用戶群體從純B端業(yè)務(wù)到覆蓋B&C端業(yè)務(wù)，業(yè)務(wù)節(jié)點(diǎn)已覆蓋4個(gè)事業(yè)群、15個(gè)事業(yè)部；對(duì)比2020年，項(xiàng)目規(guī)模已經(jīng)擴(kuò)大了11倍，公司內(nèi)共落地1000+項(xiàng)目。

框架價(jià)值=覆蓋范圍 * 功能價(jià)值。能力開發(fā)完我們需要盡可能清晰化并提升落地覆蓋，在統(tǒng)計(jì)運(yùn)營(yíng)上可以通過(guò)CI/CD平臺(tái)發(fā)布過(guò)程數(shù)據(jù)、Git倉(cāng)庫(kù)掃描數(shù)據(jù)、框架運(yùn)行時(shí)數(shù)據(jù)打點(diǎn)、IDE使用數(shù)據(jù)來(lái)做框架能力和用戶規(guī)模數(shù)據(jù)采集；同時(shí)結(jié)合標(biāo)桿團(tuán)隊(duì)、標(biāo)桿業(yè)務(wù)以組織維度框架生態(tài)能力最大提效數(shù)據(jù)，并對(duì)能力驗(yàn)證和優(yōu)化有正反饋，促進(jìn)能力高質(zhì)量、更大規(guī)模落地。

面對(duì)已建設(shè)的生態(tài)能力，如果純從能力開發(fā)視角出發(fā)、缺少有效的衡量體系，會(huì)導(dǎo)致有限的人力會(huì)被分?jǐn)偟椒浅｝嫶蟮墓こ腆w系內(nèi)：（1）已有的好能力因?yàn)闆]有度量數(shù)據(jù)，感知弱，在人員變動(dòng)等客觀背景下沒有得到持續(xù)足夠的推廣導(dǎo)致好能力沒有獲得足夠的落地，導(dǎo)致收益低于預(yù)期。（2）初期能力建設(shè)完后產(chǎn)生持續(xù)的維護(hù)成本，對(duì)部分使用率低的能力無(wú)法感知，未及時(shí)做出關(guān)鍵判斷，產(chǎn)生一部分人力浪費(fèi)。（3）對(duì)存在優(yōu)化空間的能力，由于未及時(shí)拿到使用數(shù)據(jù)，不了解落地問(wèn)題，能力未得到持續(xù)驗(yàn)證和優(yōu)化而導(dǎo)致收益不達(dá)預(yù)期。

從人力節(jié)省、質(zhì)量、縮短交付周期等方面建立有效的產(chǎn)品價(jià)值衡量體系，對(duì)齊框架年度輸出指標(biāo)并持續(xù)運(yùn)營(yíng)。

不變的是要深入結(jié)合業(yè)務(wù)架構(gòu)重點(diǎn)支撐階段核心業(yè)務(wù)場(chǎng)景，緊跟社區(qū)做一些先進(jìn)能力，同時(shí)需要通過(guò)數(shù)據(jù)來(lái)輔助判斷階段重心是提升框架核心能力覆蓋率，還是要建設(shè)新能力。

收集客服數(shù)據(jù)，沉淀高質(zhì)量的FAQ，保證增量問(wèn)題不被重復(fù)客服，引入AIGC智能客服等方式降低增量能力客服成本。

| 4.2 框架度量-全景建設(shè)

解決思路

統(tǒng)一定義并梳理指標(biāo)來(lái)源，結(jié)合上下游平臺(tái)提取數(shù)據(jù)、對(duì)缺失數(shù)據(jù)采集并持久化，通過(guò)快照等形式完成數(shù)據(jù)層聚合和差異抹平；中間層會(huì)按照定義的大盤指標(biāo)對(duì)數(shù)據(jù)進(jìn)行統(tǒng)計(jì)擬合校準(zhǔn)，包括項(xiàng)目覆蓋率、核心能力使用率、接入率、研發(fā)環(huán)節(jié)效率等等；上層會(huì)按不同的業(yè)務(wù)部門、時(shí)間區(qū)段等提供可切換的覆蓋、效能、質(zhì)量等數(shù)據(jù)看板。

• 研發(fā)過(guò)程數(shù)據(jù)持久化：覆蓋研發(fā)全流程（ 工程框架內(nèi)、插件內(nèi)、CI平臺(tái)流水線節(jié)點(diǎn)內(nèi) ）
• 生態(tài)產(chǎn)品數(shù)據(jù)埋點(diǎn)：Rome Works質(zhì)量檢測(cè)功能埋點(diǎn)等
• Talos、Fedo平臺(tái)數(shù)據(jù)庫(kù)

數(shù)據(jù)統(tǒng)計(jì)層：

• 多平臺(tái)數(shù)據(jù)Database
• 關(guān)鍵信息月度快照：支撐多維度看板的數(shù)據(jù)二次處理

大盤指標(biāo)層：

• Rome大盤指標(biāo)查詢服務(wù)：核心包含輸入輸出指標(biāo)的查詢服務(wù)
• FEDO工程化大盤指標(biāo)查詢服務(wù)：框架接入率、平均編譯構(gòu)建效率等指標(biāo)

交付（各模塊的數(shù)據(jù)看板）：

• 月度數(shù)據(jù)趨勢(shì)對(duì)比
• 可切換到餐/到店等組織維度的數(shù)據(jù)查詢展示
• 技術(shù)棧等細(xì)粒度分類的數(shù)據(jù)查詢展示

運(yùn)營(yíng)模塊：

• 數(shù)據(jù)：覆蓋率指標(biāo)的項(xiàng)目列表查詢服務(wù)；X1節(jié)點(diǎn)粒度的數(shù)據(jù)統(tǒng)計(jì)服務(wù)
• 呈現(xiàn)：大盤中增加標(biāo)桿團(tuán)隊(duì)數(shù)據(jù)圖表；增加X1節(jié)點(diǎn)的團(tuán)隊(duì)預(yù)期收益統(tǒng)計(jì)查詢服務(wù)

| 4.3 業(yè)務(wù)實(shí)踐

整體Rome業(yè)務(wù)實(shí)踐如下圖所示：截止2022年，落地了1400多個(gè)工程項(xiàng)目，資產(chǎn)庫(kù)的數(shù)量有100多個(gè)，到店多數(shù)Web項(xiàng)目是用Rome開發(fā)，大家打開美團(tuán)App，可以看到到店業(yè)務(wù)H5頁(yè)面都是通過(guò)Rome進(jìn)行開發(fā)的，有B端系統(tǒng)、C端的H5，還有我們美團(tuán)內(nèi)部的React Native。

5 總結(jié)及工程框架趨勢(shì)思考

工程框架不止于CLI。要從需求交付的視角做框架，整個(gè)工程鏈路可能涉及到應(yīng)用創(chuàng)建、應(yīng)用認(rèn)證、開發(fā)基建配置、依賴安裝、編碼、Mock、調(diào)試，包括提交Lint、還有Git、Install、Int、Build、Upload、灰度、Publish等等。

我們要核心關(guān)注高頻的、規(guī)?；?、價(jià)值比較高的環(huán)節(jié)：

1. 依賴安裝環(huán)節(jié)，因?yàn)楸镜亻_發(fā)和線上部署都會(huì)使用到，如果這部分是當(dāng)前核心的耗時(shí)點(diǎn)（ 發(fā)布總300s，依賴安裝100s ），下個(gè)階段構(gòu)建就可以先放一放，把依賴環(huán)節(jié)的優(yōu)化提上日程；
2. 開發(fā)編譯環(huán)節(jié)，很多時(shí)候開發(fā)環(huán)節(jié)我們提升了50秒，看起來(lái)好像沒有那么高，但我們團(tuán)隊(duì)如果是1000人有幾千個(gè)項(xiàng)目，調(diào)試編譯頻次是很高的，全量落地后規(guī)?；Ч蜁?huì)非常強(qiáng)；
3. 發(fā)布鏈路層面：交付鏈路中涉及整個(gè)研發(fā)的全部上下游，單純做單點(diǎn)的工程優(yōu)化（ 如本地構(gòu)建優(yōu)化 ）效果不一定好，可能到后來(lái)只是在卷幾秒的差異。部署階段依賴、構(gòu)建緩存復(fù)用可能可以直接降低 10min/次；另外部署時(shí)流水線節(jié)點(diǎn)異步觸發(fā)、測(cè)試環(huán)境聚焦提速快速看到效果，線上再補(bǔ)充管理所需的質(zhì)量分析、卡控等
4. 鏈路流轉(zhuǎn)環(huán)節(jié)：工程框架和上游的設(shè)計(jì)協(xié)作平臺(tái)怎么流轉(zhuǎn)、下游如何和部署平臺(tái)聯(lián)動(dòng)，他們的耗時(shí)可能也比較高，這部分也需要關(guān)注，因?yàn)閷?duì)使用我們這套工具的同學(xué)來(lái)說(shuō)，不關(guān)注這個(gè)能力是誰(shuí)提供，而是我們?cè)陂_發(fā)需求的時(shí)候，他明顯會(huì)感覺到你們整體提供的這套產(chǎn)品，我用起來(lái)很難受，可能不一定是工程框架部分，單體都不錯(cuò)，一起用就是不夠順滑。

未來(lái)趨勢(shì)（個(gè)人階段視角） ：

1. 第一方面是工程框架要做開發(fā)鏈路的深度整合，可以類比業(yè)界的Vercel，我們企業(yè)內(nèi)也可以類比這些成熟的像SaaS產(chǎn)品去做；
2. 第二方面是此前提到的Rust基建、構(gòu)建切換Rspack/Vite、輔助開發(fā)工具，保證生態(tài)完善，公司內(nèi)可以平滑升級(jí)；
3. AI時(shí)代：編碼Copilot；如何結(jié)合公司內(nèi)AI基建把歷史業(yè)務(wù)模板、組件庫(kù)、資產(chǎn)庫(kù)做提示生成是一個(gè)可以結(jié)合的點(diǎn)（ 框架有相對(duì)嚴(yán)格的資產(chǎn)生產(chǎn)結(jié)構(gòu)規(guī)范，可以提升下游編碼時(shí)資產(chǎn)消費(fèi)準(zhǔn)確率 ）；通過(guò)知識(shí)庫(kù)問(wèn)答降低技術(shù)項(xiàng)目的客服成本等。

----------  END  ----------

  |  美團(tuán)外賣終端容器無(wú)關(guān)化研發(fā)框架

  | 美團(tuán) iOS 端開源框架 Graver 在動(dòng)態(tài)化上的探索與實(shí)踐