1 前言

組件化開發是一種利用可重用的軟件構件來設計和開發計算機系統的過程。借助組件化開發可以實現最小化、高效交付。

平臺基礎體驗部將業務邏輯抽象為組件，通過組合組件快速構建商品Feed流，研發效率整體提升2倍。組件化開發不僅帶來效率的提升，同時極大地增加了代碼復用性、降低了系統的復雜性等等。本文將詳細介紹組件化開發的落地過程，為大家揭曉轉轉App快速迭代的奧秘。

2 背景

平臺基礎體驗部主要承接轉轉App、小程序迭代。

2021年底，基于轉轉定位于“有質檢、放心買賣的二手交易平臺”的背景，對首頁Feed（Feed，即：商品列表頁）、主搜Feed整體改造。排期時，我們發現商品卡片渲染投入耗時過多，無法完成春節前交付。短期解決方案，可以額外投入人力，按期交付。但考慮未來還會整體改版，需要尋求一種方式，能夠快速承接全平臺范圍產品迭代。

2022年3月，我們著手策劃新方案，并構建出一套組件化開發流程。

2022年9月底，距離轉轉集團宣布品牌升級還有一個月的時間，App、小程序需要整體換新，其中僅Feed功能點，升級多達20幾處。組件化開發借此契機，開始大范圍應用，效果得到了印證。

圖1 Feed改版UI示例

3 現狀分析

3.1 對接流程與開發流程

需求正式評審后，進入接口評審階段，日常對接流程如下圖所示。

圖2 對接流程

開發同學小張，根據App首頁UI圖例定字段后，同步給native以及QA。隨后著手另一功能點：App收藏夾推薦，定字段、同步字段。

接口評審后，進入開發，開發流程如下圖所示。

圖3 開發流程

RD小張開發首頁時，首先獲取各業務的RPC數據，然后自上而下寫好數據渲染邏輯。完成自測后，提供給native、QA測試環境。緊接著，投入到收藏夾功能點開發，流程類似。

看似十分順暢的流程，在執行過程中并不順利，總會有一些“小插曲”，比如：

（1）UI中出現了橫排卡片樣式，卡片上多了一個心智元素，native小劉要求增加一個userText字段。

（2）同一個UI在小程序上卻要使用不同的商品圖尺寸，FE小方大喊：給我返回16×16的尺寸！

（3）小張忙得不亦樂乎，小趙過來支援，給商品圖字段定義為infoImage，與此前的image字段命名不同，QA小張、native小李很生氣，表示我不能接受，字段不統一難于維護。

圖4 對接流程中的小插曲

對接流程問題多多，開發流程當然也沒有想象的那么順利。PM會提出一些臨時要求：在某些功能點上增加AB實驗，或者調整某處功能點的展示邏輯。RD在實現過程中可能會調整元素的渲染順序，進而影響全局數據渲染正確性，為了避免代碼調整引入額外的缺陷，QA的測試的用例也會變多。

圖5 開發流程中的小插曲

3.2 項目進展

進入開發前，RD基于現有的改動點做出技術評估，輸出排期。以App首頁、App收藏夾推薦為例，從產品規則上看，只有RPC數據源不同，RD認為大部分邏輯是可以復用的。所以，功能相近的位置可能會適當的減少排期。

但實際開發中，新的代碼邏輯與歷史邏輯存在沖突，無法順利的融入到數據渲染代碼塊。各接口的實體類定義五花八門，復用某些數據渲染方法時，存在很多實體之間的數據轉換，代碼顯得十分臃腫。很多無法預知的“小插曲”導致原本答應產品在10個工作日內完成20個Feed改造，即使加班也無法按時交付。其他職能的進度也會受到影響，給整個項目帶來風險。

圖6 項目進展

3.3 問題匯總

回顧對接、開發流程，主要暴露以下幾個問題：

• 版本、終端、UI差異增加了代碼的復雜性，難以復用：RD為了適配各端不同的樣式，或者兼容native產生的線上問題，或者為了兼容不同版本的樣式，往往要寫很多控制邏輯，使得代碼邏輯越來越臃腫，復雜性與維護成本逐漸增加。
• 接口返回值字段不統一：因為開發人員的命名習慣不一致，隨著接口的增多、產品的不斷迭代，可能會出現多個字段描述同一個功能點的情況。接口字段數量成爆炸式增長，難以維護。出現問題時，RD很難快速定位字段，溝通成本、認知成本也會大幅增加。
• 無法適應產品快速迭代：AB方案的加入、產品邏輯的調整使得元素的渲染邏輯過于龐大，元素之間的依賴關系變得更加復雜，RD無法快速交付。
• 工作內容重復，排期長，易引入延期風險：很多功能點十分相似，但是開發中無法完美復用，使得排期較長。過長的排期外加無法預知的隱藏問題，很有可能帶來延期風險。

3.4 問題切入點與解決方案

• 切入點

（1）RPC模塊、數據渲染邏輯中，有些內容完全一致，如果將他們劃分為模塊，將大幅增加代碼的復用性。

（2）數據渲染數據是過程化的、自上而下的，如果能夠打破這種串行開發模式，各數據渲染邏輯之間的耦合性大幅降低。

圖7 流程分析圖示-1

（3）深入觀察單一數據渲染內部，如果將版本兼容、終端差異、AB實驗等從數據渲染邏輯中剝離，只留下核心邏輯，數據模渲染更具復用性。

（4）不同元素的數據渲染邏輯之間難免會存在依賴關系，需要有一種資源編排機制，能夠將各數據渲染邏輯按規則組織起來。

圖8 流程分析圖示-2

• 解決方案

結合相關的技術調研以及業界相關的經驗，我們引入了《組件化開發》，即：基于組件的開發。組件、組件化開發帶來的優勢能夠達成我們的訴求，組件、組件化開發具體是什么，具有什么優勢？接下來將具體展開描述。

4 走進組件化開發

4.1 組件定義

組件是一組功能相關的邏輯、數據的聚合。

組件是自包含和完備的，通常以一組完備的API形式開放給使用者，使用者不需要了解組件內部的邏輯，只需要關注API的使用，組件的實現邏輯和依賴由組件自己負責。

4.2 組件分類

• 按職能可將組件分為：技術組件和業務組件。業務組件是把一組相關的業務邏輯封裝為一個組件，也稱為管理邏輯組件。
• 按層次可以分為：框架組件、平臺組件、通用管理邏輯組件、領域管理邏輯組件、行業管理邏輯組件、個性化管理邏輯組件等。
• 按來源可以分為：開源組件、商業組件、自研組件等。

4.3 組件模型

組件需要遵守組件模型協議。組件模型是一組標準。維多利亞大學電子與計算機工程系給出的組件模型如下圖所示。

圖9 組件模型的基礎元素

組件模型包括：接口列表、命名、元數據、互通性、自定義組件接口、組合接口、組件演進、打包與部署。

4.4 組件特點

一個設計良好的組件應該具備如下幾個特點：

• 可管理：組件是基于統一的模型進行設計和實現，遵循統一的技術規范，由統一的元數據進行描述，有清晰的分類和分層，可由組件工具進行統一管理，以規范一致的模式進行使用。
• 可復用：可復用是組件的一個核心特點。通常組件都是經過良好的設計和封裝的，可以被多個場景復用。只有能夠復用，才能更好地發揮組件的價值。
• 可配置：為了更好地復用，組件在不同的場景下使用時不需要去修改組件自身，通常組件需要把不同場景下可能會變化的部分作為可變參數，允許使用者通過配置不同的值，來滿足不同使用場景下的需求，使組件具有更好的可復用性。可配置的內容通常包括環境信息、參數、規則、模型屬性等。
• 可擴展：在使用組件的過程中，當通過配置也無法滿足場景化的使用需求時，組件的可擴展性就變得尤其重要，如果一個組件不具備可擴展性，將極大降低組件的復用價值。組件的擴展性通常可以通過良好的設計來實現，如支持繼承，可局部邏輯重寫；支持事件，通過前置后置事件，允許使用定制規則和邏輯，就可以更好地滿足不同場景下的個性化使用需求，提高組件的可復用性，發揮出組件更大的價值。

4.5 組件化開發

組件化開發： 組件化開發，即：基于組件的開發（Component-Based Development，簡稱：CBD），是一種利用可重用的軟件構件（組件）來設計和開發計算機系統的過程。

組件化開發的起源： 組件化開發出現于20世紀90年代末。當時面向對象建模開發（Object-Oriented，簡稱：OO）沒有像最初建議的那樣被廣泛的重用。OO產生了大量細粒度的類、對象和關系，在這些較小的單元中發現可重用的部件是非常困難的。CBD背后的思想是集成相關的部分并對它們進行集體重用。

4.6 組件化開發的類型

組件化開發分為兩類：機會式重用、帶有開發量的重用。

• 機會式重用：根據已有的組件組合成一套系統。

圖10 機會式重用

• 帶有開發量的重用：根據需求，定制開發某些組件，然后將組件組合成一套系統。

圖11 帶有開發量的重用

在日常的使用場景中，因為產品不斷地迭代，使用現有組件直接組合成系統的場景較少，帶有開發量的組件重用應用場景更為廣泛。

4.7 組件化開發的優勢

• 最小化交付：基于現有的組件，即可裝配成系統。
• 高效：開發人員可以更集中關注需求變更點，快速完成產品升級。
• 提升系統質量：開發人員可以有更多的時間來確保系統質量。組件的高質量決定了系統的質量。
• 減少支出：減少資源投入。

5 組件化開發的落地過程

借助組件化開發思想，我們構建了一套組件化開發架構，內部稱之為：星環，整體架構如下圖所示。

圖12 星環框架-組件化開發整體架構圖

星環體系可以總結為兩層一包：聲明層、驅動層以及業務組件包。

• 聲明層：包含基礎聲明、RPC模塊聲明、組件聲明、降級觸發規則聲明。基礎聲明以Java代碼形式聲明，剩余部分以XML形式聲明。

（1）基礎聲明：定義了應用名、應用上下文、請求參數、組件的驅動方式等。

（2）RPC模塊聲明：定義了應用中包含哪些RPC引用，RPC模塊之間的依賴關系。

（3）組件聲明：定義了應用中包含哪些業務組件、組件的屬性、組件的觸發條件。

（4）降級觸發規則聲明：定義了入口層的監控策略、降級觸發規則、監控頻率等。

• 驅動層：負責XML配置文件解析加載，RPC/組件的資源編排與執行。其中：

（1）RPC驅動層：即復仇者框架，一種自研的基于事件驅動的并發調度模型（了解更多，可查看參考文獻第5點），負責解析RPC配置聲明，編排RPC資源，執行RPC調用。

（2）組件驅動層：負責組件配置解析，組件命中判定，組件的資源編排以及提供組件驅動入口。

• 業務組件包：由業務邏輯組件構成的資源包，以jar形式管理。包含：標題組件、商品圖組件、到手價組件等。

此外，還有周邊生態為之賦能，包括：健康監測、輔助生態。

• 健康監測：檢測入口層服務健康度。當指定時間窗口內錯誤率達到上限，觸發熔斷與降級。
• 輔助生態：輔助開發人員快速構建組件應用。包含IDEA XML配置自動補全提示、maven腳手架輔助生成代碼框架等。

整個架構是如何逐步構建起來的，構建過程中有哪些需要解決的問題，下面分模塊一一介紹。

5.1 前置工作

5.1.1 統一組件口徑

首先我們要確定什么是組件，在前文中提到：組件是一組功能相關的邏輯、數據的聚合。其中，數據可以理解為接口中的每一個字段，邏輯即為每個字段所對應的產品規則。為什么把每一個字段定義為一個組件呢？這與我們的工作職能密切相關，與中臺后端不同，平臺后端是服務于前端的后端，即：BFF（Backend For Frontend）。BFF的主要職責是組合、使用底層數據，然后按照產品規則處理展示邏輯，最后返回給前端。

日常對接中，后端根據UI要求定義接口，并根據各終端特性調整接口協議。每個UI元素對應一組產品規則，每個UI元素對應一個字段。字段又作為前后端數據交互的橋梁，把每個字段劃歸為組件最合適不過。

圖13 日常對接流程

圖14 BFF開發模式

5.1.2 推進標準化

構成組件的元素是一組標準。標準的建立有助于實現組件的復用性。前文中，我們把字段定義為組件，字段、組件、UI三者之間一一對應。推進組件的標準化，也就是對字段、UI的標準化。

（1）字段命名標準化

因為開發人員的命名習慣不一致，可能會出現多個字段描述同一個功能點的情況。當以字段維度劃分不同的組件后，組件會變得非常冗余，在接口對接時也會增加溝通成本。另外，非標準化字段對native的組件化實現不是很友好，nanative需要額外維護非標字段數據與UI元素的映射，增加了開發與維護成本。

圖15 native組件化方案

（2）UI樣式標準化

雖然在不同終端、在不同頁面中UI呈現出個性化差異。但有些元素背后對應的產品邏輯是一致的。例如：商品卡片中的官方驗成色標簽傳達的內容一致，在首頁、主搜可以統一樣式。從產品角度上看，標準化的UI可以在全平臺營造統一的用戶體驗氛圍；在技術方面，不僅降低了維護API的成本，同時native根據標準化的UI可以構建出UI組件，進而豐富組件庫，提升復用性。

圖16 不同Feed的共同元素

5.1.3 規范接口返回值結構

接口返回值中包含著前端展示的各種數據，隨著產品的迭代，UI中的元素類型會越來越多，開發人員習慣性地不斷在接口返回值中平鋪新增的字段。時間周期拉長，字段數量成爆炸性增張，難以維護。因此，返回值結構也需要有一套標準，抑制字段數量增長速度。

（1）按對象內容類型收攏字段

以商品卡中的元素為例，頁面上有很多標簽元素：官方驗成色標簽、功能描述標簽、埋點標簽等，這些字段在表現形式上都為純圖片或者純文字的形式，可以統一歸納為標簽對象。

圖17 按對象內容類型收攏字段

（2）按功能合并字段

在不同的終端上，圖片鏈接有時要拼接屬性參數。以往針對圖片是否攜帶寬高屬性，我們會返回兩個字段picUrl、picUrlWH，現在統一為：picUrl。是否拼接寬高參數作為組件屬性移動到組件中。

（3）融入KV結構

KV結構用來存儲一些非標字段，如：埋點字段postIdMap，包含上報的埋點透傳字段。

（4）支持返回值VO擴展

暫時無法確認以后是否被定義為標準化字段，先放在VO的子類VOExt中。VO中只包含標準化字段聲明。

圖18 返回值VO類圖

5.2 組件粒度

獲取組件的執行結果經歷兩個步驟：執行RPC調用，然后依據產品邏輯進行數據加工。以實際使用場景為例：

渲染標題時：調用商品服務，獲取商品基礎信息。

渲染到手價時：調用商品服務，獲取商品基礎信息；調用促銷服務，獲取活動促銷信息。

渲染劃線價時：調用促銷服務，獲取活動促銷信息。

匯總RPC調用與數據渲染的關系，如下圖所示。

圖19 RPC調用與數據渲染邏輯關系圖

RPC調用與數據渲染邏輯呈現多對多的關系。再次回看組件的定義，組件是一組功能相關的邏輯、數據的聚合。功能邏輯該怎樣去定義呢？若組件的功能邏輯定義為RPC調用與數據渲染邏輯的組合，會引發以下問題：

（1）RPC重復調用：多個組件中可能包含同一RPC數據源，每個組件獲取一次RPC數據，重復調用，對下游造成壓力。

（2）組件職責不單一，難以復用：若合并多個組件，只調用一次RPC，那么組件的職責不再單一，復用性降低。

（3）難于資源編排：組件間存在依賴關系、RPC模塊間也存在依賴關系，且RPC執行順序與組件的執行順序沒有必然聯系，當RPC與數據渲染綁定在一起時，難于資源編排。

綜上，RPC調用要獨立于數據渲染邏輯，組件的功能邏輯只包含數據渲染。

進一步的，當RPC調用從組件中分離后，需要為組件提供獲取RPC數據的方式。可以在應用上下文中提供屬性域SynchronizedMap存儲RPC結果集，為二者建立通信橋梁。

圖20 RPC/數據渲染間的數據交互

5.3 組件類設計

依據組件組件遵循的組件模型協議，定義組件類包含以下內容：

• 元數據

組件類型（componentType）：標識當前組件隸屬的功能點。例如：標題組件、商品圖組件、到手價組件等等。

依賴的組件列表（dependencyComponentTypeList）：標識當前組件依賴于哪些業務組件基礎數據。例如：《券信息》數據的有無依賴于《到手價》的數據情況。

以上屬性定義在組件頂級接口中，組件頂級接口類結構如下所示。

圖21 組件頂級接口

• 行為定義

通用行為doHandle()：定義了組件的標準行為，該行為定義在組件頂級接口中。

• 自定義組件接口

自定義行為doInnerHandle()：定義了組件的自定義行為。與doHandle()的區別是：doHandle()中定義的是組件行為的通用執行邏輯，doInnerHandle()用于實現各組件的個性化業務邏輯。該行為定義在自定義組件的頂級類中，自定義組件的頂級類結構如下圖所示。

圖22 自定義組件的頂級類

基礎組件類定義好之后，還需要根據業務場景定義：定義父組件，新建業務組件。匯總類圖如下圖所示。

圖23 組件類圖

• 父組件類

自定義組件的頂級類中沒有聲明具體的返回值VO類型。在實際使用時，需要依據場景聲明返回值類型，主鍵類型，參數類型等，這些內容聲明在父組件類中。比如在Feed流商品卡片場景，新建FeedComponentHandleService，指定主鍵類型為Long類型的商品infoId、指定返回值類型為FeedBaseInfoVOExt等。

• 業務組件類

在父組件類的基礎上，可以新建業務組件類，比如：標題組件TitleV1、商品圖組件ImageV1、商品圖組件ImageV2...

5.4 參數傳遞

為了提升RPC模塊、組件的復用性，在其中會增加可變參數，允許使用者在不同場景配置不同的值。RPC/組件參數值來自于接口參數，當直接使用接口請求參數作為RPC/組件的參數時，因接口請求參數屬性域 = {RPC模塊參數屬性域，組件參數屬性域，其他參數}，RPC/組件參數中新增了很多無用參數屬性。另一方面接口參數類型多樣，同一組件難以適配不同場景中，復用性大幅降低。所以RPC/組件應該只關注自身需要使用的參數。

圖24 參數設置

接口請求參數與RPC/組件參數獨立管理后，當外界請求到來時，需要RPC/組件建立獲取接口參數的通信方式，RPC/組件獲取參數屬性值的過程如下圖所示。

圖25 獲取RPC/組件參數屬性值的過程

當獲取RPC/組件獲取參數屬性值時，首先獲取到RPC/組件請求的代理對象，然后由MethodInterceptor攔截代理對象的方法，轉而執行原始請求對象中的方法。

實現思路：

（1）定義IRequestFiledAutoMapped接口，屬性域中含有一個ThreadLocal對象用于存儲原始請求對象。RPC/組件請求類均實現該接口。

（2）定義攔截器MethodInterceptor，用于攔截IRequestFiledAutoMapped各實現類的方法請求。

（3）定義BeanProcessor，組件Bean生成后，使用Enhancer創建代理對象。

圖26 請求參數、自動映射處理類圖

5.5 組件命中條件

在傳統編程模式中，數據渲染中包含了大量的條件判斷語句，如圖所示。

圖27 耦合條件判斷的數據渲染代碼

不同的場景往往只會命中條件語句中的一個路徑。將這些條件判斷和產品功能邏輯剝離開，組件邏輯中只包含產品功能邏輯，將大幅提升組件的復用性。此外，條件的剝離可以讓功能代碼塊瘦身，開發人員的學習、認知成本將大幅減少。

回看上圖中的示例，將條件與產品功能邏輯分離后可以劃分為3個組件：

組件1：title = title + content

組件2：title = tinyTitle

組件3：title = title + paramsValue

劃分之后，可以根據不同的場景選用不同的組件，組件邏輯更易升級維護。

組件模型中規定了組合組件的接口、規則。組件的命中條件作為規則，與組件配合使用，用來判定某個場景應該選用哪個組件。實現上，我們提供了兩種條件的聲明形式。

（1）提供一個條件頂級接口IBaseCondition，實現其中的eveluation()方法，在方法中聲明命中規則。

圖28 條件頂級接口

（2）使用EL表達式描述命中規則，由Aviator規則引擎加載規則。

如何綁定條件與組件，以及如何執行命中條件，在5.6中將會展開描述。

5.6 管理多版本組件

• 管理方式

各類組件準備完畢后，需要將這些組件組織起來，如何組裝組件也需要遵循一套標準。以XML文件描述組件的裝配信息。使用這種聲明方式，各組裝點成塊狀結構，層次清晰，以下為XML的配置樣例。

圖29 demoApp1的組件配置樣例

配置文件主要包含四部分：應用聲明、RPC模塊聲明、組件聲明、自定義參數聲明。各部分聲明的內容在第5節的前置介紹中，不再贅述。

• 加載XML

轉轉的微服務由Spring Boot框架支撐，借助AbstractBeanDefinitionParser，重寫其中的parseInternal方法，解析XML，生成單例模式Bean。Bean的結構如下圖所示。

圖30 星環組件Bean結構

• 再提組件命中條件

框架中提供了兩種組件條件接入方式：實現IBaseCondition接口或者使用EL表達式。在配置文件中，聲明樣例如下圖。

圖31 組件命中規則聲明示例

（1）若實現IBaseCondition接口，則完善conditionClass的屬性值，值為IBaseCondition接口實現類的類路徑。

（2）若使用EL表達式，則完善conditionEL的屬性值，值為EL表達式內容。

• 組件命中

當條件與功能邏輯分離后，功能邏輯會演變為多個組件。因為請求場景是未知的、不確定的，將組件按照類型收攏起來為：組件組，如下圖所示。

圖32 組件組配置結構

在實際場景中，不同的場景只會命中其中的唯一一個組件，是否命中組件按照如下的規則觸發：

（1）自上而下判定組件命中。命中任意組件，則完成該組件組的判定。

（2）優先讀取conditionEL配置，規則引擎執行結果返回true則命中該組件，否則不命中；如果配置了conditionClass類路徑，執行條件實例中的evaluate方法，若方法返回值為true，則命中該組件，否則不命中。

• 組件收集

當完成某一組件組的結果判定，被命中的組件會被收集在集合中，即：Set<Class< ? extends IComponentHandleService>> 中。多個組件組的組件命中結果將匯聚在此。

5.7 組件排序

收集好組件列表之后，還不能立即執行這些組件的行為。在實際場景中，組件與組件之間存在數據依賴，如下圖所示。

圖33 組件之間的依賴

《券標簽》組件的展示條件依賴于《活動信息》組件、《到手價》組件。所以在組件執行順序上，需要將《活動信息》、《到手價》組件執行前置。底層實現上，根據組件間的依賴先后關系，排序組件。

組件之間的依賴關系可以主動聲明也可通過自動解析獲取到。排序實現上，自動解析的方式可通過三色標記的逆向解析法實現組件編排（了解更多，可查看參考文獻第10點，4.3.3章節）。我們采取主動聲明依賴，有向圖拓撲編排的方式。

具體為：

（1）編寫組件時，在組件內部聲明本組件類型、依賴的組件類型。

圖34 聲明本組件類型、依賴的組件類型

（2）將每個組件看作為圖的一個節點，依賴關系視為弧，生成一張有向圖，有向圖使用鄰接表存儲。

圖35 組件節點有向圖

圖36 組件節點鄰接表

（3）對有向圖進行拓撲排序，當有向圖存在環狀結構時，日志提示存在互相引用；若有向圖無環，則輸出最終的排序結果。

圖37 組件節點拓撲排序

（4）按序執行組件行為。

5.8 組件驅動

經過前述流程，組件模型構造完成。框架需要提供入口供外界調用。以調用場景中的實體數劃分場景為：單一視圖、多視圖。

• 單一視圖：渲染單一同類實體的數據。例如：某個商品卡片，某個商品詳情頁。
• 多視圖：渲染多個同類實體的數據。例如：多個商品卡片，多個商品詳情頁。

對于每個場景，提供相應的調用入口、自定義驅動組件列表的方法，如下圖所示。

圖38 組件調用入口類

單一視圖入口：renderView()；多視圖入口：renderViewList()。視圖入口中提供自定義驅動組件列表的方法。例如：在多視圖場景中通過實現driveCardView()方法，實現串行執行組件或并行執行組件。

5.9 新的開發模式

使用組件化開發方式，構建feed流只需要以下幾個步驟：

（1）新建業務組件（可選）：如果有新的業務邏輯，則新建業務組件類。

（2）聲明配置：在XML配置中聲明應用名、RPC模塊列表、組件列表。

（3）聲明驅動：定義應用Bean、應用上下文、請求參數、組件的驅動方式等。

（4）執行驅動：執行命中的組件列表。

（5）額外的邏輯處理：埋點日志打印等。

（6）結果返回

6 效果數據

以我的頁面增加推薦Feed場景為例：

研發側效率整體提升：2.2倍。

衡定過程：組件化模式前工時投入÷組件化模式后工時投入。即：84H÷37H≈2.2。

研發側投入成本明細如下：

圖39 研發效率明細

7 輔助生態

• XML自動補全插件

編寫組件配置時，經常需要查看組件元信息：組件的屬性等內容，影響編寫效率。基于IntelliJ Platform Plugin Template，開發了XML自動補全提示插件。

• maven腳手架（規劃中）

組件開發模式，可以沉淀一套代碼結構。腳手架生成通用代碼后，可進一步較少開發投入。

8 總結

• 傳統的開發模式：受版本、終端、產品迭代等多因素影響，隨著時間的推移，代碼邏輯越來越復雜，維護成本高，復用性低，無法應對快速的產品迭代。
• 組件化開發模式：將功能邏輯凝練為組件，代碼更具復用性。組合組件即可完成系統的構建，高效交付。

本文詳細講述了組件化開發技術的實現過程，希望對大家有所幫助。歡迎大家在評論區留言，也可添加微信號：zpc_1994，進一步交流。

9 參考文獻

[1] 畢偉.組件化軟件開發方法，2022，http://mm.chinapower.com.cn/zjqy/gddh/20221207/178571.html

[2] Margaret Rouse.Component-Based Development，2015，https://www.techopedia.com/definition/31002/component-based-development-cbd

[3] UNIC.Component-Based Development，2014，https://www.ece.uvic.ca/~itraore/seng422-06/notes/arch06-7-1.pdf

[4] 闞耀光.appview-auto-degrade-cache，2022.

[5] 陳奇恩.復雜并發場景下的并發調度模型在轉轉的演進之路，2022，https://mp.weixin.qq.com/s/6o4hQokmRytrb0Hevzly0g

[6] 陸晨，致遠，陳琦.GraphQL及元數據驅動架構在后端BFF中的實踐，2021，https://mp.weixin.qq.com/s/mhM9tfWBlIuMVkZQ-6C0Tw

[7] Sam Newman.Backends For Frontends，2015，https://samnewman.io/patterns/architectural/bff/

[8] 谷金.通用商品卡片的設計過程，2022.

[9] 陸晨，致遠，陳琦.標準化思想及組裝式架構在后端BFF中的實踐，2022，https://mp.weixin.qq.com/s/7VlXBl9syw2ppiR3x237bA

[10] 樂彬，國梁，玉龍.美團外賣廣告平臺化的探索與實踐，2022，https://mp.weixin.qq.com/s/Iyd_uYkNI5cH2sv_VwT3NA

[11] 嚴蔚敏，吳偉民.數據結構（C語言版）[M].北京：清華大學出版社，2007.163～183.