if 我是前端Leader，談談前端框架體系建設

時間 2019-12-18

標籤前端 leader 談談框架體系建設简体版

原文原文鏈接

這期來聊一聊前端框架。前端

「if 我是前端 Leader」是個人一個文章系列，說說我人在其位，欲謀其職的一些點點滴滴感悟。跟前端 Leader 只有那麼一丟丟關係，乾貨很少，但老小皆宜，不要被標題給唬住了。react

文章大綱編程

什麼是框架?

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

若是說後端框架圍繞着‘數據存儲’創建起來，那麼前端框架的基礎就是視圖庫，畢竟前端的本質工做就是視圖。這是爲何前端生態圈通常是圍繞着視圖庫展開的。因此說，前端框架的基礎是‘視圖’庫。前端工程化

若是跟後端框架(Rails, Django, Laravel...)比起來，成熟的前端框架其實很少。瀏覽器

什麼是框架？安全

看個例子。打開 UmiJS, 它對本身的描述是:性能優化

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

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

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

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

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

給個定義吧。

前端框架體系的創建離不開前端工程化成熟和‘最佳實踐‘的沉澱’。你能夠認爲框架就是一個整合的方案，提供一個前端‘最佳‘的組合配置。開發者須要作的就是在這個框架約束下填充本身業務代碼。

好處：

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

壞處:

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

前端‘框架’的發展歷程

前端框架啓蒙階段

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

它們大部分都受到後端框架的啓發，由於當年也正是後端框架最火的時候，例如 Rails。因此在它們身上會看到不少後端框架的影子。

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

野蠻生長期

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

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

因爲發展得太快，所謂的框架/最佳實踐很難被普遍接受，或者很容易就過期了，每一個人每一個團隊更熱衷於創造本身的組合方案，每每也只限於團隊內部。

前端框架整合期

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

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

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

上圖來源於<螞蟻前端研發最佳實踐> PPT

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

現有的框架都有什麼？

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

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

跟衣服的標準碼同樣。社區開源的都是通用類型框架，能夠預知的是它們沒有辦法知足全部團隊的要求。咱們每每須要根據本身業務狀況量身定製框架。

爲了應對這些需求，不一樣的框架也有不一樣的應對策略:

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

咱們也有本身的選擇策略:

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

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

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

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

上圖來源於<螞蟻前端研發最佳實踐> PPT

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

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

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

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

第一階段: 前端工程化 / 基礎設施

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

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

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

第三階段: 組件體系

組件化如今是前端主流開發模式，這裏還有不少工做能夠作，還有很大的提效空間。

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

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