來聊一聊前端架構。

什麼是框架?

這應該不是我第一次談‘框架‘了。React 是一個框架嗎？ Vue 是一個框架嗎？ 嚴格來說不是，它們只是一個視圖解決方案，這裡面算得上是框架的估計只有 Angular。

如果說後端框架圍繞著‘數據存儲’建立起來，那麼前端框架的基礎就是視圖庫，畢竟前端的本質工作就是視圖。這是為什麼前端生態圈一般是圍繞著視圖庫展開的。所以說，前端框架的基礎是‘視圖’庫。

如果跟後端框架(Rails, Django, Laravel...)比起來，成熟的前端框架其實不多。

什麼是框架？

看個例子。打開 UmiJS, 它對自己的描述是:

可插拔的企業級 react 應用框架

關鍵字是企業級。什麼是企業級，我自己也說不清楚。我只知道 React 沒有說自己是企業級，Koa、Express 也沒有，然而 Eggjs 和 Umijs 都說它們是企業級框架；Angular 通常也常常跟企業級這個概念聯繫在一起；語言層面有 Java。

對比一下他們就知道了，我覺得企業級表示它是 面向企業生產，目的是提高企業的生產力。總結一下有以下特點：

• 是高效 + 成熟方案的整合
• 關注生產的整個鏈路，而不是某個環節
• 有更強的約束和限制
• 更嚴苛的要求。性能、可擴展性(以應對不同的需求)、健壯性、穩定性、可用性、安全性
• 標準化
• 經過生產環境驗證, 有較多用例保證

歸根到底還是成本問題，框架最本質的目的就是要減低各類成本。讓更少的人可以做更多的事情、且能保證質量、降低維護成本，且能保證不斷優化和演進。

給個定義吧。

前端框架體系的建立離不開前端工程化成熟和‘最佳實踐‘的沉澱’。你可以認為框架就是一個整合的方案，提供一個前端‘最佳‘的組合配置。開發者需要做的就是在這個框架約束下填充自己業務代碼。

好處：

• 效率提升。讓開發者關注業務開發
• 學習成本降低。框架封裝了很多底層複雜性
• 更強的約束。所有動作必須按照框架規定的執行, 避免幹壞事、蠢事。更強的約束也意味著框架集成度更高、框架內部可以做更多事情，但靈活性也更低。
• 產品質量。框架內部會自動處理很多事情，例如性能優化、安全性處理
• 可維護性。所有項目都按照一致的、標準化的規範開發，升級迭代方便。這一點對團隊項目的可維護性很重要。

壞處:

• 靈活性。不能滿足所有人的需求，最佳實踐這種東西有點武斷
• 滯後性。具體方案可能會滯後。
• 大而全。對於某些項目可能過重。

前端‘框架’的發展歷程

1、前端框架啟蒙階段

在 React、Vue 流行之前已經有許多‘前端框架‘，例如 Angular、Ember、Backbone...

它們大部分都受到後端框架的啟發，因為當年也正是後端框架最火的時候，例如 Rails。所以在它們身上會看到很多後端框架的影子。

但是很多後端的開發模式，在前端有點吃不開。更本質的原因是前端工程化還不成熟，基礎相對薄弱，難以支撐上層建築的發展。

2、野蠻生長期

隨著 NodeJS 的普及、JavaScript 語言日益強大，前端工程化逐步深化。 React 這類視圖庫出來後，很多東西被打碎重構, 正所謂百花齊放，欣欣向榮。

圍繞著三大視圖庫各種各樣的庫百花齊放，前端也拓展到了瀏覽器以外的領域。人們都樂於造輪子，使用最新的技術。

由於發展得太快，所謂的框架/最佳實踐很難被廣泛接受，或者很容易就過時了，每個人每個團隊更熱衷於創造自己的組合方案，往往也只限於團隊內部。

3、前端框架整合期

幾乎每個團隊都會重複走這樣的路子：穩定技術棧、工程化建設、基礎庫/組件庫建設、沉澱自己的最佳實踐。

團隊沒有一定的工程能力和資源其實是很難將這些零散的實踐體系化、有機地粘合起來, 長期有效的維護更新更是一件難事, 半途而廢的居多。

現在前端發展開始進入平穩階段。所以大一統的前端‘框架’再一次進入人們的視野。就像 Umi 的作者 雲謙 說的: 現在是工業化時代, 框架像是一個魔法球，把各種技術棧吸到一起，加工後吐給用戶，以此來支撐業務。

框架就是將各種技術棧方案、基礎設施整合起來, 暴露標準的、一致性的接口, 讓開發者專注業務開發。

現有的框架都有什麼？

一個前端開發框架應該涵蓋前端開發鏈路的各個環節。為約束和簡化業務開發、提供有用的指導。

看看現有‘前端框架‘吧，現在社區上比較流行的‘框架’有 Angular、Next.js、Nuxt、Umi。我們橫向對比一下它們的一些特性，發現基本上包含這些東西：

跟衣服的標準碼一樣。社區開源的都是通用類型框架，可以預知的是它們沒有辦法滿足所有團隊的要求。我們往往需要根據自己業務情況量身定製框架。

為了應對這些需求，不同的框架也有不同的應對策略:

• 更開放。框架只提供核心功能，附加幾乎什麼事情都能幹的插件機制。插件可以干預框架的整個生命週期，不滿足的需求可以自己定製自己的插件
• 更決斷。我給你提供的就是最好的，能滿足你的儘量滿足你，其他的你不要管太多，也沒有必要管, 專注你的業務。

我們也有自己的選擇策略:

• 自己搞。例如大廠團隊，有資源、有豐富的實踐經驗。他們有能力將自己的‘最佳實踐’體系化。他們會選擇創建自己的框架。同時他們也樂於將經驗分享出來，也可以利用社區完善自己的作品。個人，基於學習和折騰的目的, 也可以搞一套。
• 基於開源框架擴展。可以將開源框架作為基礎，根據自己團隊情況進行擴展開發。
• 完全使用開源框架。開源框架可以滿足許多通用的需求, 適合簡單的應用場景。我們選擇一個框架主要有兩個原因：① 我們要提高工作效率；② 我們需要一個標準。 為了標準，其實可妥協一些事情。更重要的是這些框架是在不斷髮展和演進的, 從而我們團隊的技術也可以免費地跟隨他們演進和發展。將開源框架的默認最佳實踐開發視為標準。

我一直堅信專業的人做專業的事。要善於將事情外包出去，騰空自己去做重要的事情。大廠有專門的團隊在做工具、建設基礎設施，社區上開源的框架也由一大幫牛人在維護，而且通常開發迭代很活躍。所以說社區已經有的方案，可以直接拿來用，不要自己去造輪子，因為你一般沒那麼多精力。

談談前端團隊框架體系的建設

前端開發的時間都花在了哪裡?

對於前端團隊來說，開源前端框架只是一個基礎，只是涉及前端開發的某個很小的部分，它就像一艘船。你要航線穿越大西洋，還有做很多工作、需要緊密高效的協作、可靠的後勤保障、目標和方向、堅定的領導... 路還很長。

現在來聊聊‘廣義的‘框架體系，它集成自身業務，涉及前端開發完整鏈路，關注點從前端應用上升到了前端團隊研發體系。

九層之臺，起於累土。 前端團隊框架體系的建設是一個漸進式的過程，首先從基礎設施開始、接著就是應用開發技術棧組合，再到組件體系，後面是上層的業務開發方案... 上層以下層為基礎，共同構建出完整的框架體系。

我覺得前端團隊可以按照這樣的分層結構，分階段來完成這些建設任務。

最基礎的階段，關注前端的基礎設施建設。這個階段已經比較成熟，社區上有很多開箱即用的方案，例如 Umi、Next.js、Vue-CLI、Create-React-App 等等。主要內容有:

第二階段: 應用開發方案整合

在完善基礎設施的同時，團隊的應用開發技術棧組合方案也應該穩定下來，成為框架的一部分。這些組合也非常重要，它會影響上層的組件建設和業務開發。主要內容有:

第三階段: 組件體系

組件化現在是前端主流開發模式，這裡還有很多工作可以做，還有很大的提效空間。

整個組件體系也是一個分層式的結構：

• 基礎組件。越底層，就說明可複用的程度越高、越通用。Ant-Design、Element-UI、iView、Material-UI 這些就屬於基礎組件庫，有能力的團隊也可以開發一套符合自己設計風格的組件庫。
• 業務組件。在基礎組件之上封裝的、耦合自己業務的組件。它們一般從重複的業務場景中抽象出來。
• 區塊。再往上，就很難用模塊化的組件去組織了。於是有人(阿里前端)提出了‘區塊’的概念，你可以認為‘區塊’是：代碼片段、代碼示例、代碼模板... 這麼看來，這並不是一種新的概念? 還沒完! 區塊還要配套‘區塊市場’才能展現它的用處。區塊市場是一個代碼片段分享平臺，維護著大量的區塊，試圖覆蓋大部分常見的使用場景。對於開發者來說就是找到儘量匹配自己場景的區塊，拷貝過來，稍微改改就行了。這是一種 ‘Ctrl+C，Ctrl+V’ 編程哲學的完美實踐啊。
• 頁面。和區塊差不多，快速生成頁面和路由。約定式的路由可以給頁面自動化創建帶來一些便利。
• 佈局。例如後臺的整體佈局。
• 項目。項目的整體結構。可以通過‘腳手架‘ 來快速生成項目模板。

第四階段：打通上下游

前端只是研發流程的一環，只是前端自嗨，上下游沒有資源支持，是很難走遠的。

對於前端來說，通常上游指的是 UI、下游指的是後端。

對於 UI。上面說的組件體系，其實是建立在穩定的、一致的、統一的 UI 設計語言之上的。否則一切都是空談。所以我們要求 UI 設計團隊要有良好的設計規範、能和前端組件體系綁定並良性迭代。

對於 後端。可以促進建立更標準的接口範式、封裝通用的服務(有利於業務組件複用)、更深的有業務中臺、BFF...

上下游的打通，對前端生產力的解放也有非常大的促進作用。

如果喜歡，歡迎關注我，並轉發此文章~你們的喜歡是我的動力！

閱讀更多 IT技術管理那些事兒 的文章

關鍵字: Node.js Djang 前端