### 前言 一位計算機前輩曾說過： Controlling complexity is the essence of computer programming. 隨著前端開發復雜度的日益提升，組件化開發應運而生，并隨著 FIS、React 等優秀框架的出現遍地開花。這一過程同樣發生在美團，面臨業務規模的快速發展和工程師團隊的不斷擴張，我們歷經引入組件化解決資源整合問題、逐步增強組件功能促進開發效率、重新打造新一代組件化方案適應全棧開發和共享共建等階段，努力“controlling complexity”。本文將介紹我們組件化開發的實踐過程。 ### 組件化 1.0：資源重組 在美團早期，前端資源是按照頁面或者類似業務頁面集合的形式進行組織的。例如 order.js 對應訂單相關頁面的交互，account.css 對應賬戶相關頁面的樣式。這種方式在過去的較長一段時間內，持續支撐了整個項目的正常推進，功勛卓著。 <center></center> 隨著業務規模的增加和開發團隊的擴張，這套機制逐漸顯示出它的一些不足： * 資源冗余 頁面的逐漸增加，交互的逐漸復雜化，導致對應的 css 和 js 都有大幅度增長，進而出現為了依賴某個 js 中的一個函數，需要加載整個模塊，或者為了使用某個 css 中的部分樣式依賴整個 css，冗余資源較多 * 對應關系不直觀 沒有顯而易見的對應規則，導致的一個問題是修改某個業務模塊的 css 或者 js 時，幾乎只能依靠 grep。靠人來維護頁面模塊 html、css 和 js 之間的依賴關系，容易犯錯，常常出現內容已經刪除但是 css 或 js 還存在的問題 * 難于單元測試 以頁面為最小粒度進行資源整合，不同功能的業務模塊相互影響，復雜度太高，自動化測試難以推進 ...