一篇文章讀懂什么是前端工程化

發(fā)布時(shí)間：2021-06-22 15:26:45

1. 什么是前端工程化

自有前端工程師這個(gè)稱謂以來，前端的發(fā)展可謂是日新月異。相比較已經(jīng)非常成熟的其他領(lǐng)域，前端雖是后起之秀，但其野蠻生長(zhǎng)是其他領(lǐng)域不能比的。雖然前端技術(shù)飛快發(fā)展，但是前端整體的工程生態(tài)并沒有同步跟進(jìn)。目前絕大多數(shù)的前端團(tuán)隊(duì)仍然使用非常原始的“切圖（FE）->套模板（RD）”的開發(fā)模式，這種模式下的前端開發(fā)雖說不是刀耕火種的原始狀態(tài)，但是效率非常低下。

前端的工程化問題與傳統(tǒng)的軟件工程雖然有所不同，但是面臨的問題是一樣的。我們首先回顧一下傳統(tǒng)的軟件開發(fā)流程模型：

上圖中的運(yùn)行和維護(hù)并不是串行關(guān)系，也并非絕對(duì)的并行關(guān)系。維護(hù)貫穿從編碼到運(yùn)行的整個(gè)流程。

如果說計(jì)算機(jī)科學(xué)要解決的是系統(tǒng)的某個(gè)具體問題，或者更通俗點(diǎn)說是面向編碼的，那么工程化要解決的是如何提高整個(gè)系統(tǒng)生產(chǎn)效率。所以，與其說軟件工程是一門科學(xué)，不如說它更偏向于管理學(xué)和方法論。

軟件工程是個(gè)很寬泛的話題，每個(gè)人都有自己的理解。以上是筆者個(gè)人的理解，僅供參考。

具體到前端工程化，面臨的問題是如何提高編碼->測(cè)試->維護(hù)階段的生產(chǎn)效率。

可能會(huì)有人認(rèn)為應(yīng)該包括需求分析和設(shè)計(jì)階段，上圖展示的軟件開發(fā)模型中，這兩個(gè)階段具體到前端開發(fā)領(lǐng)域，更恰當(dāng)?shù)姆Q謂應(yīng)該是功能需求分析和UI設(shè)計(jì)，分別由產(chǎn)品經(jīng)理和UI工程師完成。至于API需求分析和API設(shè)計(jì)，應(yīng)該包括在編碼階段。

2. 前端工程化面臨的問題

要解決前端工程化的問題，可以從兩個(gè)角度入手：開發(fā)和部署。

從開發(fā)角度，要解決的問題包括：

1. 提高開發(fā)生產(chǎn)效率；

2. 降低維護(hù)難度。

這兩個(gè)問題的解決方案有兩點(diǎn)：

1. 制定開發(fā)規(guī)范，提高團(tuán)隊(duì)協(xié)作能力；

2. 分治。軟件工程中有個(gè)很重要的概念叫做模塊化開發(fā)其中心思想就是分治。

從部署角度，要解決的問題主要是資源管理，包括：

1. 代碼審查；

2. 壓縮打包；

3. 增量更新；

4. 單元測(cè)試；

要解決上述問題，需要引入構(gòu)建/編譯階段。

2.1 開發(fā)規(guī)范

開發(fā)規(guī)范的目的是統(tǒng)一團(tuán)隊(duì)成員的編碼規(guī)范，便于團(tuán)隊(duì)協(xié)作和代碼維護(hù)。開發(fā)規(guī)范沒有統(tǒng)一的標(biāo)準(zhǔn)，每個(gè)團(tuán)隊(duì)可以建立自己的一套規(guī)范體系。

值得一提的是JavaScript的開發(fā)規(guī)范，尤其是在ES2015越來越普及的局面下，保持良好的編碼風(fēng)格是非常必要的。筆者推薦Airbnb的eslint規(guī)范。

2.2 模塊/組件化開發(fā)

2.2.1 模塊還是組件？

很多人會(huì)混淆模塊化開發(fā)和組件化開發(fā)。但是嚴(yán)格來講，組件（component）和模塊（module）應(yīng)該是兩個(gè)不同的概念。兩者的區(qū)別主要在顆粒度方面。《Documenting Software Architectures》一書中對(duì)于component和module的解釋如下：

A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.

In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.

簡(jiǎn)單講，module側(cè)重的是對(duì)屬性的封裝，重心是在設(shè)計(jì)和開發(fā)階段，不關(guān)注runtime的邏輯。module是一個(gè)白盒；而component是一個(gè)可以獨(dú)立部署的軟件單元，面向的是runtime，側(cè)重于產(chǎn)品的功能性。component是一個(gè)黑盒，內(nèi)部的邏輯是不可見的。

用通俗的話講，模塊可以理解為零件，比如輪胎上的螺絲釘；而組件則是輪胎，是具備某項(xiàng)完整功能的一個(gè)整體。具體到前端領(lǐng)域，一個(gè)button是一個(gè)模塊，一個(gè)包括多個(gè)button的nav是一個(gè)組件。

模塊和組件的爭(zhēng)論由來已久，甚至某些編程語言對(duì)兩者的實(shí)現(xiàn)都模糊不清。前端領(lǐng)域也是如此，使用過bower的同行知道bower安裝的第三方依賴目錄是bower_component；而npm安裝的目錄是node_modules。也沒必要為了這個(gè)爭(zhēng)得頭破血流，一個(gè)團(tuán)隊(duì)只要統(tǒng)一思想，保證開發(fā)效率就可以了。至于是命名為module還是component都無所謂。

筆者個(gè)人傾向組件黑盒、模塊白盒這種思想。

2.2.2 模塊/組件化開發(fā)的必要性

隨著web應(yīng)用規(guī)模越來越大，模塊/組件化開發(fā)的需求就顯得越來越迫切。模塊/組件化開發(fā)的核心思想是分治，主要針對(duì)的是開發(fā)和維護(hù)階段。

關(guān)于組件化開發(fā)的討論和實(shí)踐，業(yè)界有很多同行做了非常詳細(xì)的介紹，本文的重點(diǎn)并非關(guān)注組件化開發(fā)的詳細(xì)方案，便不再贅述了。筆者收集了一些資料可供參考：

1. Web應(yīng)用的組件化開發(fā)；

2. 前端組件化開發(fā)實(shí)踐;

3. 大規(guī)模的前端組件化與模塊化。

3. 構(gòu)建&編譯

嚴(yán)謹(jǐn)?shù)刂v，構(gòu)建（build）和編譯（compile）是完全不一樣的兩個(gè)概念。兩者的顆粒度不同，compile面對(duì)的是單文件的編譯，build是建立在compile的基礎(chǔ)上，對(duì)全部文件進(jìn)行編譯。在很多Java IDE中還有另外一個(gè)概念：make。make也是建立在compile的基礎(chǔ)上，但是只會(huì)編譯有改動(dòng)的文件，以提高生產(chǎn)效率。本文不探討build、compile、make的深層運(yùn)行機(jī)制，下文所述的前段工程化中構(gòu)建&編譯階段簡(jiǎn)稱為構(gòu)建階段。

3.1 構(gòu)建在前端工程中的角色

在討論具體如何組織構(gòu)建任務(wù)之前，我們首先探討一下在整個(gè)前端工程系統(tǒng)中，構(gòu)建階段扮演的是什么角色。

首先，我們看看目前這個(gè)時(shí)間點(diǎn)（2016年），一個(gè)典型的web前后端協(xié)作模式是什么樣的。請(qǐng)看下圖：

上圖是一個(gè)比較成熟的前后端協(xié)作體系。當(dāng)然，目前由于Node.js的流行開始普及大前端的概念，稍后會(huì)講述。

自Node.js問世以來，前端圈子一直傳播著一個(gè)詞：顛覆。前端工程師要借助Node.js顛覆以往的web開發(fā)模式，簡(jiǎn)單說就是用Node.js取代php、ruby、python等語言搭建web server，在這個(gè)顛覆運(yùn)動(dòng)中，JavaScript是前端工程師的信心源泉。我們不討論Node.js與php們的對(duì)比，只在可行性這個(gè)角度來講，大前端這個(gè)方向吸引越來越多的前端工程師。

其實(shí)大前端也可以理解為全棧工程師，全棧的概念與編程語言沒有相關(guān)性，核心的競(jìng)爭(zhēng)力是對(duì)整個(gè)web產(chǎn)品從前到后的理解和掌握。

那么在大前端模式下，構(gòu)建又是扮演什么角色呢？請(qǐng)看下圖：

大前端體系下，前端開發(fā)人員掌握著Node.js搭建的web server層。與上文提到的常規(guī)前端開發(fā)體系下相比，省略了mock server的角色，但是構(gòu)建在大前端體系下的作用并沒有發(fā)生改變。也就是說，不論是大前端還是“小”前端，構(gòu)建階段在兩種模式下的作用完全一致，構(gòu)建的作用就是對(duì)靜態(tài)資源以及模板進(jìn)行處理，換句話說：構(gòu)建的核心是資源管理。

3.2 資源管理要做什么？

前端的資源可以分為靜態(tài)資源和模板。模板對(duì)靜態(tài)資源是引用關(guān)系，兩者相輔相成，構(gòu)建過程中需要對(duì)兩種資源使用不同的構(gòu)建策略。

目前仍然有大多數(shù)公司將模板交由后端開發(fā)人員控制，前端人員寫好demo交給后端程序員“套模板”。這種協(xié)作模式效率是非常低的，模板層交由前端開發(fā)人員負(fù)責(zé)能夠很大程度上提高工作效率。

3.2.1 靜態(tài)資源構(gòu)建策略

靜態(tài)資源包括js、css、圖片等文件，目前隨著一些新規(guī)范和css預(yù)編譯器的普及，通常開發(fā)階段的靜態(tài)資源是：

1. es6/7規(guī)范的文件；

2. less/sass等文件（具體看團(tuán)隊(duì)技術(shù)選型）；

3. [可選]獨(dú)立的小圖標(biāo)，在構(gòu)建階段使用工具處理成spirit圖片。

構(gòu)建階段在處理這些靜態(tài)文件時(shí)，基本的功能應(yīng)包括：

1. es6/7轉(zhuǎn)譯，比如babel；

2. 將less/sass編譯成css；

3. spirit圖片生成；

以上提到的幾個(gè)功能可以說是為了彌補(bǔ)瀏覽器自身功能的缺陷，也可以理解為面向語言本身的，我們可以將這些功能統(tǒng)稱為預(yù)編譯。

除了語言本身，靜態(tài)資源的構(gòu)建處理還需要考慮web應(yīng)用的性能因素。比如開發(fā)階段使用組件化開發(fā)模式，每個(gè)組件有獨(dú)立的js/css/圖片等文件，如果不做處理每個(gè)文件獨(dú)立上線的話，無疑會(huì)增加http請(qǐng)求的數(shù)量，從而影響web應(yīng)用的性能表現(xiàn)。針對(duì)諸如此類的問題，構(gòu)建階段需要包括以下功能：

1. 依賴打包。分析文件依賴關(guān)系，將同步依賴的的文件打包在一起，減少http請(qǐng)求數(shù)量；

2. 資源嵌入。比如小于10KB的圖片編譯為base64格式嵌入文檔，減少一次http請(qǐng)求；

3. 文件壓縮。減小文件體積；

4. hash指紋。通過給文件名加入hash指紋，以應(yīng)對(duì)瀏覽器緩存引起的靜態(tài)資源更新問題；

5. 代碼審查。避免上線文件的低級(jí)錯(cuò)誤；

以上幾個(gè)功能除了壓縮是完全自動(dòng)化的，其他兩個(gè)功能都需要人工的配置。比如為了提升首屏渲染性能，開發(fā)人員在開發(fā)階段需要盡量減少同步依賴文件的數(shù)量。

以上提到的所有功能可以理解為工具層面的構(gòu)建功能。

以上提到的構(gòu)建功能只是構(gòu)建工具的基本功能。如果停留在這個(gè)階段，那么也算是個(gè)及格的構(gòu)建工具了，但也僅僅停留在工具層面。對(duì)比目前較流行的一些構(gòu)建產(chǎn)品，比如fis，它具備以上所得的編譯功能，同時(shí)提供了一些機(jī)制以提高開發(fā)階段的生產(chǎn)效率。包括：

1. 文件監(jiān)聽。配合動(dòng)態(tài)構(gòu)建、瀏覽器自動(dòng)刷新等功能，提高開發(fā)效率；

2. mock server。并非所有前端團(tuán)隊(duì)都是大前端（事實(shí)上很少團(tuán)隊(duì)是大前端），即使在大前端體系下，mock server的存在也是很有必要的；

我們也可以將上面提到的功能理解為平臺(tái)層面的構(gòu)建功能。

3.2.2 模板的構(gòu)建策略

模板與靜態(tài)資源是容器-模塊關(guān)系。模板直接引用靜態(tài)資源，經(jīng)過構(gòu)建后，靜態(tài)資源的改動(dòng)有以下幾點(diǎn)：

1. url改變。開發(fā)環(huán)境與線上環(huán)境的url肯定是不同的，不同類型的資源甚至根據(jù)項(xiàng)目的CDN策略放在不同的服務(wù)器上；

2. 文件名改變。靜態(tài)資源經(jīng)過構(gòu)建之后，文件名被加上hash指紋，內(nèi)容的改動(dòng)導(dǎo)致hash指紋的改變。

其實(shí)url包括文件名的改動(dòng)，之所以將兩者分開論述是為了讓讀者區(qū)分CDN與構(gòu)建對(duì)資源的不同影響。

對(duì)于模板的構(gòu)建宗旨是在靜態(tài)資源url和文件名改變后，同步更新模板中資源的引用地址。

現(xiàn)在有種論調(diào)是脫離模板的依賴，html由客戶端模板引擎渲染，簡(jiǎn)單說就是文檔內(nèi)容由JavaScript生成，服務(wù)端模板只提供一個(gè)空殼子和基礎(chǔ)的靜態(tài)資源引用。這種模式越來越普遍，一些較成熟的框架也驅(qū)動(dòng)了這個(gè)模式的發(fā)展，比如React、Vue等。但目前大多數(shù)web產(chǎn)品為了提高首屏的性能表現(xiàn)，仍然無法脫離對(duì)服務(wù)端渲染的依賴。所以對(duì)模板的構(gòu)建處理仍然很有必要性。

具體的構(gòu)建策略根據(jù)每個(gè)團(tuán)隊(duì)的情況有所差異，比如有些團(tuán)隊(duì)中模板由后端工程師負(fù)責(zé)，這種模式下fis的資源映射表機(jī)制是非常好的解決方案。本文不討論具體的構(gòu)建策略，后續(xù)文章會(huì)詳細(xì)講述。

模板的構(gòu)建是工具層面的功能。

3.2.3 小結(jié)

構(gòu)建可以分為工具層面和平臺(tái)層面的功能：

• 工具層面

1. 預(yù)編譯，包括es6/7語法轉(zhuǎn)譯、css預(yù)編譯器處理、spirit圖片生成；

2. 依賴打包；

3. 資源嵌入；

4. 文件壓縮；

5. hash指紋；

6. 代碼審查；

7. 模板構(gòu)建。

• 平臺(tái)層面

1. 文件監(jiān)聽，動(dòng)態(tài)編譯；

2. mock server。

4. 總結(jié)

一個(gè)完整的前端工程體系應(yīng)該包括：

1. 統(tǒng)一的開發(fā)規(guī)范；

2. 組件化開發(fā)；

3. 構(gòu)建流程。

開發(fā)規(guī)范和組件化開發(fā)面向的開發(fā)階段，宗旨是提高團(tuán)隊(duì)協(xié)作能力，提高開發(fā)效率并降低維護(hù)成本。

構(gòu)建工具和平臺(tái)解決了web產(chǎn)品一系列的工程問題，旨在提高web產(chǎn)品的性能表現(xiàn)，提高開發(fā)效率。

隨著Node.js的流行，對(duì)于前端的定義越來越寬泛，在整個(gè)web開發(fā)體系中。前端工程師的角色越來越重要。本文論述的前端工程體系沒有涉及Node.js這一層面，當(dāng)一個(gè)團(tuán)隊(duì)步入大前端時(shí)代，前端的定義已經(jīng)不僅僅是“前端”了，我想Web工程師這個(gè)稱號(hào)更合適一些。

之前跟一位前端架構(gòu)師討論構(gòu)建中對(duì)于模塊化的處理時(shí)，他提到一個(gè)很有意思的觀點(diǎn)：所謂的壓縮打包等為了性能做出的構(gòu)建，其實(shí)是受限于客戶端本身。試想，如果未來的瀏覽器支持大規(guī)模并發(fā)請(qǐng)求、網(wǎng)絡(luò)延遲小到微不足道，我們還需要壓縮打包嗎？

誠然，任何架構(gòu)也好，策略也好，都是對(duì)當(dāng)前的一種解決方案，并不是一條條鐵律。脫離了時(shí)代，任何技術(shù)討論都沒有意義。