隨著SPA，前后端分離的技術(shù)架構(gòu)在業(yè)界越來越流行,，前端需要管理的內(nèi)容,，承擔的職責也越來越多。再加上移動互聯(lián)網(wǎng)的火爆,，各大公司也開始在前端投入更多的資源,。

在傳統(tǒng)的開發(fā)模式中，不僅會有大量的資源冗余,，而且因為項目中的交叉依賴太多,，當出現(xiàn)技術(shù)方案變化時，IT無法做到漸進式的,、有節(jié)奏地替換掉老的代碼,，只能一次性替換掉所有老代碼，極大地提升了技術(shù)方案升級的成本和風險,。并且業(yè)務的要求,，UX的設計都需要等到開發(fā)人員寫完代碼，整個項目編譯部署后才能看到實際的效果,。反饋周期太長,，而未來的任何一個小修改又需要重復這一整個流程，以致于無法發(fā)揮一個團隊的全部效能,，部分成員會出現(xiàn)等待空窗期,，浪費團隊效率。

這一切,，使得業(yè)界對前端開發(fā)方案的思考上多了很多,，以快速開發(fā)框架為代表推動的組件化開發(fā)方案成為了目前比較認可的方案。

組件化開發(fā)的核心是“業(yè)務的歸業(yè)務,，組件的歸組件”,，即組件是一個個獨立存在的模塊。使用組件化開發(fā)讓原有到系統(tǒng)級的粗粒度控制細化到了組件級別的細粒度控制,，一個復雜系統(tǒng)的構(gòu)建就是組件最終集成后的一個結(jié)果,，開發(fā)人員可以很容易了解該組件提供的能力。而每個組件都自己獨立的版本,，可以獨立編譯,、獨立打包和部署，不與全局或其他組件產(chǎn)生影響,。

把系統(tǒng)的構(gòu)建架構(gòu)在組件化思想上可以降低上手難度和整個系統(tǒng)的耦合度,，由于每個組件的職責單一,，在系統(tǒng)中更容易被復用，所以對某個職責的修改只需要修改一處,，就可獲得系統(tǒng)的整體升級,。獨立的，小的組件代碼更易理解,，維護起來也更容易,。通過對組件的拆分粒度控制來合理分配團隊成員任務，讓團隊中每個人都能發(fā)揮所長,，維護對應的組件,，最大化團隊開發(fā)效率。

具體來說,，在前端項目中,，構(gòu)建各個UI界面占了80%以上的工作量。而通過抽象,，我們會發(fā)現(xiàn)大量的組件可以在多個UI界面上復用,。在組件化開發(fā)方案下，團隊在交付開始階段就從架構(gòu)層面對應用的UI進行模塊化,，IT部門把需求分析階段產(chǎn)生的原型中的每一個UI頁面抽象為一顆組件樹,，UI頁面自己本身上也是一個組件。這樣的抽象顯著降低了項目的工作量,，在組件上對樣式進行調(diào)整也會變得容易,，對后續(xù)的修改和維護的影響范圍也能得到控制。

另一種典型的場景則是某個功能界面,，距離啟動界面有多個層級，按照傳統(tǒng)開發(fā)方式,，需要按照頁面一頁一頁地開發(fā),，當前一個頁面開發(fā)未完成時，無法開始下一個頁面的開發(fā),，導致團隊工作的并發(fā)度不夠,。另外，在團隊中,，開發(fā)人員的能力各有所長,，而頁面依賴降低了整個項目在任務安排上的靈活性，無法按照團隊成員的經(jīng)驗,，強項來合理安排工作,。這兩項對團隊協(xié)同度的影響最終會拉低團隊的整體效率。

而組件化開發(fā)強調(diào)業(yè)務任務和組件任務的分離和協(xié)同,。組件任務具有很強的獨立性和自治性,，即在接口定義清楚的情況下,，完全可以拋開上下文進行開發(fā)。這類任務對外無任何依賴,，再加上組件的職責單一性,，其功能也很容易被開發(fā)者理解。所以在安排任務上,，組件任務可以非常靈活,。

隨著前后端分離架構(gòu)成為主流，越來越多的業(yè)務邏輯被推向前端,，再加上用戶對于體驗的更高要求,，前端的復雜性在一步一步地拔高。對前端復雜性的管理就顯得越來越重要,。

組件化開發(fā)不僅可以解決當前的項目交付效率難題,，還指導了團隊的運作，幫助了后期的演進,，甚至在程序員最討厭的寫文檔的方面也給出了一個巧妙的解法,，是企業(yè)開發(fā)軟件降本增效的利器。