淺談前端工程化

 

第一章 背景及現狀

　　不知道你的團隊如何定義前端開發，據我所知，時至今日仍然有不少團隊會把前端開發歸類爲產品或者設計崗位（這點本人深有體會！！！），雖然身份之爭多少有些無謂，但我對這種偏見仍是心存芥蒂，試着從工程的角度系統的介紹一下我對前端，尤爲是對web前端的理解。只要咱們還把本身的工做看做爲一項軟件開發活動，那麼我相信讀過下面的內容你也必定會有所共鳴。

　　前端，是一種GUI軟件！

　　現現在前端可謂一應俱全，產品形態五花八門，涉獵極廣，什麼高大上的基礎庫/框架，拽炫酷的宣傳頁面，還有屌炸天的小遊戲……不過這些一兩個文件的小項目並不是是前端技術的主要應用場景，更具商業價值的則是複雜的Web應用，它們功能完善，界面繁多，爲用戶提供了完整的產品體驗，多是新聞聚合網站，多是在線購物平臺，多是社交網絡，多是金融信貸應用，多是音樂互動社區，也多是視頻上傳與分享平臺，多是系統應用，門戶、數據可視化平臺……

　　從本質上講，全部Web應用都是一種運行在網頁瀏覽器中的軟件，這些軟件的圖形用戶界面（Graphical User Interface，簡稱GUI）即爲前端。

　　如此複雜的Web應用，動輒幾十上百人共同開發維護，其前端界面一般也頗具規模，工程量不亞於通常的傳統GUI軟件。

　　儘管Web應用的複雜程度與日俱增，用戶對其前端界面也提出了更高的要求，但時至今日仍然沒有多少前端開發者會從軟件工程的角度去思考前端開發，來助力團隊的開發效率，更有甚者還對前端保留着」如玩具般簡單「的刻板印象，日復一日，刀耕火種。

　　「歷史悠久」的前端開發，始終像是放養的野孩子，原始如斯，難免讓人慨嘆！

　　隨着前端開發複雜度的日益增長，各類優秀的組件框架也遍地開花。同時，咱們面臨業務規模的快速發展和工程師團隊的不斷擴張。目前來講，Web業務日益複雜化和多元化，前端開發已經由以WebPage模式爲主轉變爲以WebApp模式爲主了。如今隨便找個前端項目，都已經不是過去的拼個頁面+搞幾個jQuery插件就能完成的了。工程複雜了就會產生許多問題，如何進行高效的多人協做？如何保證項目的可維護性？如何提升項目的開發質量？...

　　咱們但願能在平常開發中制訂一個規範化的前端工做流，很好地規範統一項目的模塊化開發和前端資源，讓代碼的維護和互相協做更加容易更加方便，令前端開發自動化成爲一種習慣。同時，讓你們可以釋放生產力，提升開發效率，更好更快地完成團隊開發以及項目後期維護和擴展。

第二章 構建前端工程的幾個階段

2.1 第一階段：庫/框架選型

　　前端工程建設的第一項任務就是根據項目特徵進行技術選型（ps:以上排序不分排名前後）。

　　基本上如今沒有人徹底從0開始作網站，哪怕是政府項目用個jQuery都很正常吧，React/Vue/Angular等框架橫空出世，解放了很多生產力，合理的技術選型能夠爲項目節省許多工程量這點毋庸置疑。

2.2 第二階段：構建、管理工具

　　選型以後基本上就能夠開始敲碼了，不過光解決開發效率還不夠，必需要兼顧運行性能。前端工程進行到第二階段會選型一種或多種構建工具，對代碼進行壓縮、校驗、管理，以後再以頁面爲單位進行簡單的資源合併（ps:以上排序不分排名前後）。

　　前端開發工程化程度之低，經常出乎咱們的意料。不少人在大型互聯網公司工做時是沒有多少概念的，直到離開大公司的溫室，去到業界與更多的團隊交流才發現，能作到這個階段在業界來講已然超出平均水平，屬於「具有較高工程化程度」的團隊了，查看網上形形色色的網頁源代碼，能作到最基本的JS/CSS壓縮的Web應用都已跨入標準互聯網公司行列，不難理解爲何不少前端團隊對於前端工程構建的認知還僅停留在「壓縮、校驗、合併」這種程度。

2.3 第三階段：JS/CSS模塊化開發

　　分而治之是軟件工程中的重要思想，是複雜系統開發和維護的基石，這點放在前端開發中一樣適用。在解決了基本開發效率運行效率問題以後，前端團隊開始思考維護效率，模塊化是目前前端最流行的分治手段（ps:以上排序不分排名前後）。

　　不少人以爲模塊化開發的工程意義是複用，其實應該是模塊化開發的最大價值應該是分治。無論你未來是否要複用某段代碼，你都有充分的理由將其分治爲一個模塊。

　　JS模塊化方案不少，AMD/CommonJS/UMD/ES6 Module等，對應的框架和工具也一大堆；CSS模塊化開發基本都是在less、sass、stylus等預處理器的import/mixin特性支持下實現的。雖然這些技術由來已久，在現在這個「言必及React」的時代略顯落伍，但想一想業界的絕大多數團隊的工程化落後程度，放眼望去，絕不誇張的說，能達到第三階段的前端團隊已屬於高端行列，基本具有了開發維護通常規模Web應用的能力。

　　

　　尤爲是node的出現，除了用JS能夠寫服務端業務，衆多的模塊化、構建工具結合node真的是豐富了整個前端生態圈。

　　然而，作到這些就夠了麼？

2.4 第四階段：組件化開發與資源管理

　　前端是一種技術問題較少、工程問題較多的軟件開發領域。

　　當咱們要開發一款完整的Web應用時，前端將面臨更多的工程問題，好比：

1. 大致量：多功能、多頁面、多狀態、多系統；
2. 大規模：多人甚至多團隊合做開發；
3. 高性能：CDN部署、緩存控制、文件指紋、緩存複用、請求合併、按需加載、同步/異步加載、移動端首屏CSS內嵌、HTTP 2.0服務端資源推送。

　　這些無疑是一系列嚴肅的系統工程問題。前面講的三個階段雖然相比曾經「茹毛飲血」的時代進步很多，但用於支撐第四階段的多人合做開發以及精細的性能優化彷佛還欠缺點什麼。到底，缺什麼呢？

2.4.1 組件化開發

　　前端從來以「簡單」著稱，在前端開發者羣體中，小而美的價值觀佔據着主要的話語權，甚至成爲了某種信仰，想與其餘人交流一下工程方面的心得，獲得的迴應每每都是兩個字：過重。

　　工程方案其實也能夠小而美！只不過它的小而美不是指代碼量，而是指「規則」。找到問題的根源，用最少最簡單明瞭的規則制定出最容易遵照最容易理解的開發規範或工具，以提高開發效率和工程質量，這一樣是小而美的典範！

　　分治的確是很是重要的工程優化手段。在我看來，前端做爲一種GUI軟件，光有JS/CSS的模塊化還不夠，對於UI組件的分治也有着一樣迫切的需求：

　　如上圖，這是我所信仰的前端組件化開發理念，簡單解讀一下：

1. 頁面上的每一個 獨立的 可視/可交互區域視爲一個組件；
2. 每一個組件對應一個工程目錄，組件所需的各類資源都在這個目錄下就近維護；
3. 因爲組件具備獨立性，所以組件與組件之間能夠 自由組合；
4. 頁面只不過是組件的容器，負責組合組件造成功能完整的界面；
5. 當不須要某個組件，或者想要替換組件時，能夠整個目錄刪除/替換。

　　其中第二項描述的就近維護原則，是最具工程價值的地方，它爲前端開發提供了很好的分治策略，每一個開發者都將清楚的知道，本身所開發維護的功能單元，其代碼必然存在於對應的組件目錄中，在那個目錄下能找到有關這個功能單元的全部內部邏輯，樣式也好，JS也好，頁面結構也好，都在那裏。

　　組件化開發具備較高的通用性，不管是前端渲染的單頁面應用，仍是後端模板渲染的多頁面應用，組件化開發的概念都能適用。組件HTML部分根據業務選型的不一樣，能夠是靜態的HTML文件，能夠是前端模板，也能夠是後端模板：

　　不一樣的技術選型決定了不一樣的組件封裝和調用策略。

　　基於這樣的工程理念，咱們很容易將系統以獨立的組件爲單元進行分工劃分：

 

　　因爲系統功能被分治到獨立的模塊或組件中，粒度比較精細，組織形式鬆散，開發者之間不會產生開發時序的依賴，大幅提高並行的開發效率，理論上容許隨時加入新成員認領組件開發或維護工做，也更容易支持多個團隊共同維護一個大型站點的開發。

　　結合前面提到的模塊化開發，整個前端項目能夠劃分爲這麼幾種開發概念：

名稱	說明	舉例
JS模塊	獨立的算法和數據單元	瀏覽器環境檢測(detect)，網絡請求(ajax)，應用配置(config)，DOM操做(dom)，工具函數(utils)，以及組件裏的JS單元
CSS模塊	獨立的功能性樣式單元	reset樣式，柵格系統(grid)，字體圖標(icon-fonts)，動畫樣式(animate)，以及組件裏的CSS單元
UI組件	獨立的可視/可交互功能單元	頁頭(header)，頁尾(footer)，導航欄(nav)，搜索框(search)
頁面	前端這種GUI軟件的界面狀態，是UI組件的容器	首頁(index)，列表頁(list)，用戶管理(user)
應用	整個項目或整個站點被稱之爲應用，由多個頁面組成	SPA（單一頁面應用）、PWA（漸進式Web應用）

　　以上5種開發概念以相對較少的規則組成了前端開發的基本工程結構，基於這些理念，前端開發就成了這個樣子：

示意圖	描述
	整個Web應用由頁面組成
	頁面由組件組成
	一個組件一個目錄，資源就近維護
	組件可組合， 組件的JS可依賴其餘JS模塊， CSS可依賴其餘CSS單元

　　綜合上面的描述，對於通常中小規模的項目，大體能夠規劃出這樣的源碼目錄結構：

 

　　若是項目規模較大，涉及多個團隊協做，還能夠將具備相關業務功能的頁面組織在一塊兒，造成一個子系統，進一步將整個站點拆分出多個子系統來分配給不一樣團隊維護。以上架構設計歷經許多不一樣公司不一樣業務場景的前端團隊驗證，收穫了不錯的口碑，是行之有效的前端工程分治方案。

2.4.2 靜態資源管理

　　上面提到的模塊化/組件化開發，僅僅描述了一種開發理念，也能夠認爲是一種開發規範，假若你承認這規範，對它的分治策略產生了共鳴，那咱們就能夠繼續聊聊它的具體實現了。

　　很明顯，模塊化/組件化開發以後，咱們最終要解決的，就是模塊/組件加載的技術問題。然而前端與客戶端GUI軟件有一個很大的不一樣：前端是一種遠程部署，運行時增量下載的GUI軟件。

　　前端應用沒有安裝過程，其所需程序資源都部署在遠程服務器，用戶使用瀏覽器訪問不一樣的頁面來加載不一樣的資源，隨着頁面訪問的增長，漸進式的將整個程序下載到本地運行，「增量下載」是前端在工程上有別於客戶端GUI軟件的根本緣由。

 

　　上圖展現了一款界面繁多功能豐富的應用，若是採用Web實現，相信也是不小的體量，若是用戶第一次訪問頁面就強制其加載全站靜態資源再展現，相信會有不少用戶由於失去耐心而流失。根據「增量」的原則，咱們應該精心規劃每一個頁面的資源加載策略，使得用戶不管訪問哪一個頁面都能按需加載頁面所需資源，沒訪問過的無需加載，訪問過的能夠緩存複用，最終帶來流暢的應用體驗。

　　這正是Web應用「免安裝」的魅力所在。由「增量」原則引伸出的前端優化技巧幾乎成爲了性能優化的核心，有加載相關的按需加載、延遲加載、預加載、請求合併等策略；有緩存相關的瀏覽器緩存利用，緩存更新、緩存共享、非覆蓋式發佈等方案；還有複雜的BigRender、BigPipe、Quickling、PageCache等技術。這些優化方案無不圍繞着如何將增量原則作到極致而展開。

　　因此：第四階段前端開發最迫切須要作好的就是在基礎架構中貫徹增量原則。

　　相信這種貫徹不會隨着時間的推移而改變，在可預見的將來，不管在ES5亦或者ES6/7時代，不管是AMD/CommonJS/UMD亦或者ES6 module時代，不管端內技術如何變遷，咱們都有足夠充分的理由要作好前端程序資源的增量加載。正如前面說到的，第三階段前端工程缺乏點什麼呢？我以爲是在其基礎架構中缺乏這樣一種「智能」的資源加載方案。沒有這樣的方案，很難將前端應用的規模發展到第四階段，很難實現落地前面介紹的那種組件化開發方案，也很難讓多方合做高效率的完成一項大型應用的開發，並保證其最終運行性能良好。在第四階段，咱們須要強大的工程化手段來管理」玩具般簡單「的前端開發。

2.5 第五階段：規範化

　　模塊化和組件化肯定了開發模型，而這些東西的實現就須要規範去落實。規範化實際上是工程化中很重要的一個部分，項目初期規範制定的好壞會直接影響到後期的開發質量：

• 目錄結構的制定
• 編碼規範
• 先後端接口規範
• 文檔規範
• 組件管理
• Git分支管理
• Commit描述規範
• 按期CodeReview
• 視覺圖標規範
• ...

2.6 總結

　　在業界內有這麼一句話：任何簡單機械的重複勞動都應該讓機器去完成。現代前端技術再也不是之前刀耕火種的年代了。因此前端工程化的不少髒活累活都應該交給自動化工具來完成。

　　我的總結經驗，認爲前端工程化主要應該從模塊化、組件化、規範化、自動化四個方面來思考。

　　如何選型技術、如何定製規範、如何分治系統、如何優化性能、如何加載資源，當你從切圖開始轉變爲思考這些問題的時候，我想說：你好，工程師！

　　最後要特別感謝「Fouber」工程師（https://github.com/fouber/）的精心分享。