前端有架構嗎？

本文首發於 歐雷流。因爲我會時不時對文章進行補充、修正和潤色，爲了保證所看到的是最新版本，請閱讀 原文。

從事前端開發的你，不知有沒有被問過：「前端有架構嗎？」

問你的人的身份，多是你的 boss 或上司，多是後端同事，也多是前端同行；問你的人的目的，多是刁難，多是嘲諷，也多是請教。

前端開發

衆所周知，作前端開發所依賴的核心技術就是 HTML、CSS 和 JS，就像好基友同樣如影隨行，咱們將它們仨親切地並稱爲「三劍客」。

通過這二十多年，尤爲是在 V8 引擎及 Node.js 出現以後，以「三劍客」爲基礎的衍生技術如雨後春筍般大量出現，前端及其關聯社區與前端工程師這個職業獲得了空前的蓬勃發展，甚至讓不少人以爲一個前端工程師不只僅能夠作 web 前端開發，還能夠寫後端，替代客戶端工程師——前端技術一統天下！

工做內容

除了作網頁，前端技術還能應用於命令行工具、客戶端應用、服務端應用、聊天機器人、爬蟲、IoT 等場景。只要腦洞足夠大，就不怕場景不夠多。

然而，絕大部分的前端工程師在工做中都會接觸到這些嗎？

試想一下，本身的工做歷程是否是這樣的——

在一家 150 人規模如下的創業公司，可能業務還在摸索期，須要不斷地快速試錯以找到能夠鉚足勁兒去發力的點。這時前端團隊也沒幾我的，可能就三五個吧，而且 leader 不是什麼大牛，也沒有一套方法論做爲團隊建設的指導，也許你是這個團隊裏實力最強的。

這個時期所須要的就是可以快速迭代產出成果，而後去驗證是否有效。根本不會給你時間去思考、規劃前端團隊的發展方向與基礎設施建設。若是特地花費時間去作這些，沒準兒公司會認爲你「遊手好閒」，到時 KPI 打個不及格。

經歷一段時間的焦頭爛額，在此期間工程目錄、代碼提交極可能都很隨意，而且沒有 code review。有空閒下來回頭一看，代碼一坨一坨跟那個什麼似的，實現與「優雅」這個詞絕緣。

隨着業務的快速發展，項目、應用愈來愈多，團隊人數也愈來愈多，然而規範約定、基礎設施依然幾乎沒有。在業務線作開發的前端，也不太會想着整個團隊的工具統一，本身怎麼爽就怎麼來。最終致使一個團隊用了多種視圖層庫、多個組件庫，給收斂技術棧帶來很大阻礙。

終於，公司的業務開始走上正軌，前端團隊也已經有二三十人了，胸懷大志、急他人所不急的你以爲再這樣野蠻生長下去是確定不行的，靠堆人力去知足快速發展且多變的業務需求是很是低效且低級的方式，必需要有技術上的基礎設施去支撐！即便公司層面不容許工做時間去作這種長遠看來對公司是百利而無一害的事情，也要去作，就業餘時間去作！

在全部基礎設施中，最初級、最能直接體現出開發提效成果的，就是高度抽象的 UI 框架。通過了不知多少個的「下班後」和「週末」，可算搞出了個可以知足必定業務場景的，在本身負責的幾個應用中初見成效。

正當你爲本身所作的事情如指望中那樣獲得了收益而感到欣慰時，忽然有人冒出來質疑你所作的事情，而且有可能就是前端團隊中的。還好有其餘人對你作的事表示承認，以爲有價值，讓你有動力在這件事上繼續下去。也許他是個後端開發，願意去用，或願意幫你在部門中推廣。

你不斷地給 UI 框架增長新的功能，並千方百計去改造舊系統。在公司拓展業務所須要的新應用和之前老應用的維護中，你所作的東西確確實實節省了很多人力和資源。在有新的一批後端開發入職時，還會邀請你在新人培訓上給他們講解如何使用你所開發的 UI 框架輔助完成工做。這結結實實地打了當初質疑你的人的臉。

後臺系統頁面的常見模式就是供數據 CRUD 的列表頁、表單頁和詳情頁，當把支撐這些場景的交互和數據處理的核心邏輯都已經抽象了以後，你發現再怎麼完善 UI 框架也不會有像以前那樣比較明顯的效率提高，頂可能是優化了交互和開發體驗，使功能更穩定而已。

你陷入了思考：「該作些什麼才能繼續爲開發提效呢？」

以前作的 UI 框架，是對交互邏輯和數據邏輯進行了高度封裝，並提供了大量的 CSS class 和工具方法。雖然使在作頁面時能夠少寫不少 CSS 和 JS 代碼，但對於 HTML 代碼來講並無減小。

貌似找到了該突破的點，但要怎麼去作呢？

冥思苦想，你忽然靈光乍現，想起了本身曾經用過的基於「世界上最好的語言」開發的博客系統——WordPress。既而後臺系統頁面如此模式化，何不效仿 WordPress 將不易變的部分做爲「主題」，易變的部分做爲「文章」？

這樣作會帶來另一個好處，就是將頁面代碼數據化了，有什麼純前端的問題修改就只是數據修正，而不用走冗長繁雜的運維發佈流程。往後若是公司有了本身的設計語言，再加入可視化搭建的特性，業務後臺系統的開發和維護前端就不太用參與了！

理想狀況下，產品經理用已有物料拖拖拽拽生成「原型」，該「原型」就是最終界面；業務功能肯定後，後端開發定模型、寫接口，而後配置界面的數據展現。這樣一來，業務系統迭代的整個過程當中，基本能夠忽略前端這個角色了。

那麼前端幹什麼呢？在這樣的協做模式下，前端的主要工做就是完善物料庫，而且讓產品經理和後端開發使用起來更方便。這種提效方式所帶來的收益，與開發 UI 框架相比，根本不是一個層次的，想一想都以爲興奮！

然而，理想的豐滿遮不住現實的骨感。聽到你的想法的人，要麼質疑地問你一些問題，要麼嘴上表示支持心理暗地譏笑——不想些怎麼讓業務發展起來的事情，成天想什麼亂七八糟、花裏胡哨的東西！

你以爲內心憋屈，認爲他們目光短淺，看不透本質。但爲了本身所認爲所堅信的「正確」，就算沒有人在心理上或行動上有所支持，也要朝着那個方向努力，嘗試作一把！

通過一段時間的折騰，你開始感到有些作不下去了。一方面是由於，雖然 Node.js 的出現讓前端開發人員也可以開發服務端，但數據庫等服務端開發領域所需知識和思惟方式匱乏，導致設計很不合理，寫出來的程序也很差；另外一方面，公司層面不指望你投入較多的時間在短時間內對業務發展沒有太大幫助的事情，就連 KPI 的指標設定都是很業務化的，等 KPI 評分時分數確定很低。

在這家公司裏，你也算是「老員工」了，對公司的品性也較爲深入瞭解，自覺本身所認爲所堅信的「正確」在這裏得不到認真對待，至少很長一段時間以內是，你甚是失望，甚至絕望。其實，你早如此感受，只是不肯面對，老是但願本身的信念可以多多少少影響到組織的認知，然而徒勞。

從 UI 框架到頁面數據化，在作這些事情時你都是獨自一人、孤軍奮戰，突然內心感到一絲悲涼。你最終黯然離開，想去大廠裏去看看，也許那裏可以讓你實現技術理想。

當你真正進了大廠，並且是個業務部門時，你會發現作的事情和以前並沒太大差異，仍然是業務爲重。不一樣的是，可能你的領導和身邊的同事，對你的想法是真心認同的，他們會盡力支持你想作的事情，併爲你提供幫助。

你幡然醒悟：不管在小廠、中廠仍是大廠，只要是在業務部門，UI 框架、命令行工具基本就是在技術上所能作的極限，要想更上一層，就得在平臺部門。

提效方式

前面屢次提到了「提效」這個詞，它是什麼？簡單粗暴地講，就是縮減業務需求的研發時間，這是全部開發人員所追求的。若是有可能，只需需求方本身動動手操做下就完成。

那麼該如何提效呢？我所能想到的，大概有：

• 基於各視圖層庫的具備一致 API 的 UI 框架；
• 可以覆蓋整個研發流程的命令行工具；
• 將一份源碼編譯/轉譯成不一樣目標平臺代碼的工具；
• 頁面數據化並支持可視化搭建的平臺。

這幾點，每一個展開往深了弄都是頗有價值的事情，須要耗費不少心血，甚至能夠做爲一個產品或開一家公司了！

前端架構

在繼續往下進行以前，先讓咱們來稍微探討下「前端有架構嗎？」這個問題。

有架構嗎？

「架構」是什麼？架構是一組抽象概念，像「人」，像「寵物」，讓你沒必要關注他是誰，它是什麼動物；架構是一張圖，讓你可以清楚地瞭解不一樣事物是怎麼歸類的，它們之間是如何聯繫到一塊，如何進行協做的；架構是指導思想，告訴你什麼該作、什麼不應作，指引你把代碼寫到正確的地方；架構是一套方法論，讓你知道在哪些場景下遇到哪類問題該怎樣去解決……

引用維基百科的話——

Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.

基於上述描述，若是前端開發只是單純的靜態頁面，即只有 HTML 和 CSS，或 JS 只做爲添加特效使用，不操做數據，沒有通訊，那麼能夠說「前端沒架構可言」。但，如今從事前端開發的人，有幾我的的工做是這樣的呢？

我想，從事前端開發的你的工做不是作頁面，而是應用開發吧？那麼，架構就是必不可少的了。你也許會疑惑：「我連這聽起來逼格很高的詞具體是指啥都不知道，怎麼可能會有？！」

之因此無所察覺，是由於你沒有刻意去思考並進行架構設計。想一想看，你是不符合如下情形：

• 根據社區裏總結的最佳實踐，或者與他人交流時受到啓發，在開發時將代碼邏輯拆分紅不一樣模塊，並將幾個具有一些相同特徵的模塊放到一個目錄下；
• 用 Umi 或 Vue 全家桶開發單頁面應用。

這兩種狀況均可以說是使用了分層架構模式，前者是你無心間進行的，後者是人家幫你作好了的。

好的架構？

既然「前端有架構嗎？」這個問題的答案是確定的，「什麼樣的架構是好架構？」就成爲了下一個問題。

在說「什麼樣的架構是好架構？」以前，先插入另一個問題，有興趣的話能夠先行思考下：一個足夠複雜的前端框架，與瀏覽器、操做系統之間有什麼相同點？

迴歸正題。我認爲一個好的架構應該是這樣的——

幫公司更輕鬆地賺錢。這點是最重要的，對於一個企業來講，若是軟件不能讓本身賺錢，爲何要用它？幫助公司賺錢的方式無非就兩種，「開源節流」。「開源」比較難，須要瞭解行業並洞悉商機，對人自己資質的要求過高；「節流」相對就簡單了，減小研發投入，即上文所說的「提效」。

第二重要的，就是「穩定」。一個差不離兒的架構，至少得能支撐業務發展三五年吧？雖然公司未必能活那麼久。這就須要在作架構設計時可以面向將來：一是業務的將來，二是技術的將來。面向將來的架構必須擴展性好、足夠靈活，這樣纔有可能應對各類業務場景及突如其來的業務變化。

以上是我以爲一個好的架構的兩個核心標準，每一個點都會牽扯到不少事情，就不在此多說。

在對一個系統進行架構設計時，會用到多種架構模式，如：分層模式、管道和過濾器模式、微內核模式、微服務模式、MVC/MVVM 模式等。在實現時又會用到多種設計模式、數據結構與算法。

所以，要學習並掌握它們，而後根據（潛在）業務目標與（潛在）應用場景去選擇最適合的運用到架構設計和框架實現當中。

核心原則

在作前端架構時，我認爲該遵照幾個基本原則——

第一個是「以不變爲中心」。

軟件開發的本質就是操做數據，放在 web 開發的場景，後端是存儲、獲取數據，前端是收集、展現數據。

數據在前、後端流轉時，數據的基本形態不會變：基本類型、對象、列表；數據的傳輸協議也不會變：HTTP、WebSocket。在前端開發中，離它們越遠、離 GUI 越近的東西就越容易變。

因此，首先要作的就是梳理出哪些東西是不易變化的，哪些是很容易就變了的。

第二個是「各層皆可替換」。

將根據易變性梳理出的模塊按職責進行分層，定義好層與層之間的對接協議（接口）。除了因自身進化須要，對接協議是基本不會變的，也不該去改變。以此爲前提，各層實現可在業務須要或技術升級時進行替換。

第三個是「視圖層儘量薄」。

視圖層的職責是展現數據，理應只有交互邏輯，而大多數前端在寫 UI 組件時會摻雜較多的業務邏輯，使視圖層變得非常厚重、臃腫。這樣一來，業務邏輯不利於複用，也會增長視圖層技術的遷移成本。應將業務邏輯進行抽象，並提取到領域層，讓視圖層保持純粹。

因爲視圖層的易變、多樣，並想讓它儘量薄，最好有什麼方式可以增長它訪問邏輯層的成本，就像前端只能經過網絡請求訪問後端同樣。

突然想到在作業務開發時有遇到過這種架構，你有印象嗎？沒錯，就是微信小程序！微信小程序的架構是將邏輯層與視圖層放到不一樣的線程中運行，從而作到了自然隔離，它們之間交流的媒介只有「數據」：

微信小程序是創建在客戶端應用提供一些原生能力基礎之上的，那麼在瀏覽器中可以達到相同或相似的效果嗎？固然能夠！瀏覽器提供原生能力，視圖層運行在 iframe 中，邏輯層則在 web worker 裏：

覺不以爲這很像「微前端」架構——據我理解，簡單來講就是一種可以讓不一樣技術棧的模塊同時運行在瀏覽器中，它們能夠是組件也能夠是應用，而且相互之間可以通訊、協同工做的架構模式。

基於這種架構，能夠開發出一個相似於瀏覽器、操做系統的「超級 app」，成爲平臺級應用。

若是你在平臺部門，上文說的也許就是你要面對的事情。

開源項目

前段時間，某廠的前端團隊開源了一套組件庫，當時我在想：若是作不到比 Ant Design 優秀，開源個組件庫的意義在哪？

出自螞蟻金服的 Ant Design，不管從設計（視覺設計、代碼設計，各類設計）仍是從實現來看都已經很優秀了，API 設計十分考究，國內很難有出其右的做品。

若是說在某個視圖層技術或某個端沒有其對應的實現，與其本身從頭造輪子，還不如實現一個在那個視圖層技術或那個端的 Ant Design 版本。

以前我一直認爲通過幾十年的發展，GUI 的交互形式已經相對固定，不太會有什麼突破，若是已經存在了一套非常優秀的交互模式庫，後來者如果沒有什麼可以與其抗爭的亮點，在競爭上無疑是以卵擊石。

直到聽到叔叔說：

開放的意義並非代碼，而是有自身對交互的理解，若是作不到這點，那開放組件庫就沒有意義。

一開始沒怎麼理解這句話的內涵，以後的幾天時不時會想到這句話，琢磨其中的含義。以後突然明白了——這不就跟寫文章同樣嗎？！寫做難道是爲了讓別人看到本身的文字？固然不是！是想用文字記錄並表達本身對這個世界、人、事、物的理解。難道已經有人寫過相同或相似觀點的文章，且寫得十分好，本身就不能寫了嗎？固然不是！

原來如此。

其實任何帶有創做性質的行爲都是同樣的，都是經過某個途徑來表達本身的思想，寫文章是，寫代碼是，繪畫是，作菜也是。正如荒木老師的書上所說——

最近，我要開始作一個「大」項目。實際是前幾年就想作的，只不過當時沒想好到底要作些什麼，但核心理念是一致的——反混沌！連項目名都起好了，就叫「Anti-chaos」。

爲何要作這麼一個項目？還不是由於前端圈太混亂？雖然與前些年相比稍微好了那麼一點，但跟 Java 圈相比，亂太多了。我但願「Anti-chaos」能成爲盤古之斧，劈開混沌，清者爲天，濁者爲地。

那麼「Anti-chaos」要作些什麼？就如剛纔所說，這是一個「大」項目，由於它基本要覆蓋當前前端開發的方方面面。

我並非想開發一個大而全的框架，而是要遵守「反混沌」的思想拆分紅多個小項目，每一個都是解決某個固定場景的問題，它們能夠組合並擴展成適合某個團隊、企業的解決方案，從而使前端開發乃至前端圈變得更加有序。

以前我也是基於相似的想法，想讓「前端工程師」這個職業相關的一些事情變得更加標準、有序，然而這件事操做起來實在是太困難了，比安靜地寫代碼難上不知道多少倍，因此目前處於擱置狀態。等「Anti-chaos」有所成效以後，再看狀況是否重啓那個項目吧。

總結

做爲前端工程師，在業務部門所能接觸到的技術以及眼界的提升是有限的，一是在作業務時用不上什麼太前沿的技術，二是業務部門的性質不會容許也沒有資源讓你作太多深刻的思考和嘗試。

要想真正地提高本身的技術能力和眼界，最好仍是去平臺部門吧！剛開始時也許會以爲很吃力，這是由於你爲了適應環境而在進行思惟模式的轉變。等你適應了，你就會發覺本身在思考問題時與後端愈來愈接近，也會愈來愈以爲不管作前端仍是作後端，所須要的知識和能力是差很少的，只是要解決的問題不一樣。

一我的的水平不能用年齡和年限去衡量，要看他有多少經歷，都經歷過什麼。

本文主要闡述了我最近一段時間對前端開發、前端架構以及開源項目等方面的思考及現階段的理解，不必定對，可是我目前的看法。

正所謂——

參禪之初，看山是山，看水是水；禪有悟時，看山不是山，看水不是水；禪中徹悟，看山仍然是山，看水仍然是水。

以上。