降本增效的利器——元件化開發

隨著 SPA，前後端分離的技術架構在業界越來越流行，前端需要管理的內容，承擔的職責也越來越多。再加上移動網際網路的火爆，各大公司也開始在前端投入更多的資源。

在傳統的開發模式中，不僅會有 大量的資源冗餘 ， 而且 因為專案中的交叉依賴太多，當出現技術方案變化時， IT  無法做到漸進式的、有節奏地替換掉老的程式碼，只能一次性替換掉所有老程式碼，極大地提升了技術方案升級的成本和風險。 並且 業務的要求， UX的設計都需要等到開發人員寫完程式碼，整個專案編譯部署後才能看到實際的效果 。 反饋週期太長， 而 未來的任何一個小修改又需要重複這一整個流程 ， 以致於 無法發揮一個團隊的全部效能，部分成員會出現等待空窗期，浪費團隊效率。

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

元件化開發的核心是“業務的歸業務，元件的歸元件” ， 即元件是一個個獨立存在的模組 。 使用 元件化開發 讓 原有到系統級的粗粒度控制細化到了元件級別的細粒度控制，一個複雜系統的構建就是元件最終整合後的一個結果，  開發人員可以很容易瞭解該元件提供的能力 。 而 每個元件都自己獨立的版本，可以獨立編譯、獨立打包和部署， 不與全域性或其他元件產生影響 。

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

具體來說， 在前端專案中，構建各個 UI介面佔了 80%以上的工作量 。 而透過 抽象 ， 我們會發現大量的元件可以在多個 UI介面上覆用 。 在元件化開發方案下，團隊在交付開始階段就從架構層面對應用的 UI進行模組化， IT部門  把需求分析階段產生的原型中的每一個 UI頁面抽象為一個元件樹， UI頁面自己本身上也是一個元件。這樣的抽象顯著降低了專案的工作量，在元件上對樣式進行調整也會變得容易，對後續的修改和維護  的影響範圍也能得到控制。

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

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

隨著前後端分離架構成為主流，越來越多的業務邏輯被推向前端，再加上使用者對於體驗的更高要求，前端的複雜性在一步一步的拔高。對前端複雜性的管理就顯得越來越重要。

元件化開發不僅 可以解決 當前的專案交付 效率難題 ，還指導了團隊的運作，幫助了後期的演進，甚至在程式設計師最討厭的寫文件的方面也給出了一個巧妙的解法 ， 是企業開發軟體降本增效的利器。