雖然前端工程化的概念興起還沒幾年的時間，但是對于“工程化”這個詞并不是一個新鮮詞了，在其他軟件開發(fā)的領(lǐng)域很早就已經(jīng)有了高度的工程化，例如Web服務(wù)端開發(fā)。只不過那個時候，前端工程師并沒有工程化的意識，也沒有必要對前端進(jìn)行工程化的操作，畢竟在那個時期，前端的開發(fā)工作只能算是整個項目開發(fā)過程中的“附屬品”。那為什么這幾年，前端工程化的概念又突然成為了熱點話題了呢？要想講好前端工程化其實并不容易，我就從下面幾個方面入手，對前端工程化的概念做個簡單的講解，僅僅是個人理解，希望大家多多交流討論。

1、前端為什么要工程化？

在回答前端工程化這個問題之前，我們應(yīng)該先考慮另外一個問題：前端開發(fā)中會不會涉及到業(yè)務(wù)？再詳細(xì)一點，就是前端工程師到底需不需要了解服務(wù)端的業(yè)務(wù)邏輯，再或者說，要不要將一部分服務(wù)端的業(yè)務(wù)邏輯放到前端來實現(xiàn)。這個問題沒有標(biāo)準(zhǔn)的答案，實際上應(yīng)該屬于工程協(xié)作問題，就是誰該干什么的問題。

最早的前端開發(fā)就是實現(xiàn)頁面，頂多再寫寫JS讓頁面可以有交互的特效。但是隨著需求的增加，我們不僅要做Web應(yīng)用，還要做App、小程序以及各種端。在這種需求日增的情況下，必須得考慮一種新的方式，優(yōu)化前端的開發(fā)工作，例如，解決代碼冗余，項目可維護(hù)性，提升版本迭代速度等等一系列的問題。前端工程化的概念也就是在這中情況下被提出了。

2、實現(xiàn)前端工程化的基礎(chǔ)——前后端分離

實際上，現(xiàn)在的前端工程化應(yīng)該還處于早期階段，畢竟前端工程師這個崗位也才誕生沒幾年。在互聯(lián)網(wǎng)發(fā)展的早期，Web應(yīng)用很多情況下都是由服務(wù)端工程師一肩挑，前端開發(fā)頂多是寫寫HTML代碼，實現(xiàn)頁面的布局，然后再把寫好的HTML靜態(tài)文件交給后端工程師套模板，因為當(dāng)時大部分的Web應(yīng)用都是使用的服務(wù)端渲染技術(shù)，例如Java的JSP。

這種傳統(tǒng)模式下的協(xié)作開發(fā)效率非常低，如果在頁面測試中發(fā)現(xiàn)了一個bug，這個bug是由于一個ClassName的值少寫了一個字母，你說這種情況到底是前端工程師的錯，還是后端工程師套模板時的粗心大意呢？畢竟一個網(wǎng)站上有成千上萬個DOM節(jié)點，誰也不能保證一行代碼都不會寫錯。再假如，項目上線后發(fā)現(xiàn)網(wǎng)頁的實際像素和設(shè)計稿上存在1像素的偏差，這個時候就需要由前端工程師重新設(shè)計一次HTML靜態(tài)頁面，然后再交給后端工程師繼續(xù)套模板，等整個流程走完之后，你會發(fā)現(xiàn)一個更加嚴(yán)重的問題，整個項目中僅僅是1像素的偏差，就有可能要調(diào)動整個開發(fā)團(tuán)隊來處理這1像素的問題，極大的浪費了團(tuán)隊資源。

上面的問題也僅僅是傳統(tǒng)開發(fā)問題中的冰山一角，面對這么多的問題，前后端分離開發(fā)也就應(yīng)運而生了。前后端分離開發(fā)，為前端工程化的發(fā)展提供了生存的土壤。隨著市場需求的不斷變化，前端開發(fā)從傳統(tǒng)的WebPage模式，轉(zhuǎn)變到WebApp模式，Web產(chǎn)品形態(tài)的變化也不斷推動著前端工程師的工作內(nèi)容發(fā)生變化。在應(yīng)對各種“變化”，前端工程師們也要設(shè)計出自己的前端開發(fā)“方法論”。

前端工程化的主要目標(biāo)就是解放生產(chǎn)力、提高生產(chǎn)效率。通過制定一系列的規(guī)范，借助工具和框架解決前端開發(fā)以及前后端協(xié)作過程中的痛點和難度問題。

3、如何實施前端工程化？

明確前后端開發(fā)的分工，是實現(xiàn)前后端分離的第一步，也是后面實現(xiàn)前端各種優(yōu)化方案的基礎(chǔ)。前端工程師主要負(fù)責(zé)的內(nèi)容包括：

靜態(tài)資源和動態(tài)資源的處理；JavaScript實現(xiàn)前端業(yè)務(wù)邏輯；HTML模板文件的產(chǎn)出；中間層Web服務(wù)，一般由Node.js實現(xiàn)；前端單元測試；前端項目部署；

其中，靜態(tài)資源包括.js文件、.css文件以及各種格式的圖片、媒體文件等，這些文件不依賴于服務(wù)器，只需要在瀏覽器里面解析就可以了；動態(tài)資源是指HTML的模板，如果項目不是由服務(wù)器完成渲染的SPA（單頁面）應(yīng)用，那我們就要考慮如何實現(xiàn)HTML模板的渲染了。前端項目部署是指靜態(tài)資源文件在測試服務(wù)器上的部署，以及HTML模板文件在Node.js中間層服務(wù)器上的部署。

從項目開發(fā)的整體環(huán)節(jié)來說，實現(xiàn)前端工程化還需要熟練掌握下面幾個方面：

（1）使用Webpack實現(xiàn)項目構(gòu)建

構(gòu)建，簡單來說就是編譯，前端開發(fā)的所有文件最終歸屬是要交給瀏覽器去解析、渲染，并將頁面呈現(xiàn)給用戶，構(gòu)建就是將前端開發(fā)中的所有源代碼轉(zhuǎn)化為宿主瀏覽器可以執(zhí)行的代碼。前端構(gòu)建產(chǎn)出的資源文件只有三種，HTML、CSS、JS文件。需要完成編譯的內(nèi)容有：

無法被瀏覽器直接識別的JS代碼，包括ES6/7/8/9/10等符合ECMAScript規(guī)范的JS代碼；無法被瀏覽器直接識別的CSS代碼，包括SASS/LESS等預(yù)編譯的CSS語法；無法被瀏覽器識別的HTML模板代碼，包括jade、ejs、artTemplate、mustache等Node.js模板引擎；

項目構(gòu)建其實就是為了彌補瀏覽器自身的缺陷和不足，是一種面向語言的編譯過程。那么，除了針對語言本身之外，前端的構(gòu)建還應(yīng)該考慮到Web應(yīng)用的性能優(yōu)化。這些優(yōu)化主要是為了減少HTTP請求，提升用戶體驗，包括：

依賴打包，將同步依賴的文件打包在一起，減少HTTP請求數(shù)量；資源嵌入，例如將小于10kb的圖片編譯為格式嵌入文檔，減少HTTP請求；文件壓縮，減少文件體積，縮短請求時間；為文件加入hash指紋，以應(yīng)對瀏覽器緩存策略；將開發(fā)環(huán)境下的域名與靜態(tài)資源文件路徑修改為生產(chǎn)環(huán)境下的域名和路徑；文件名稱的改變；

這里需要解釋一下，前端的構(gòu)建工具除了Webpack之外，還有其他的工具，例如Gulp、Grunt等，為什么這里只提到了Webpack？其實，Gulp、Grunt只能算是工作流管理工具，它們本身是不提供具體的功能，所有的構(gòu)建、部署等功能都要由對應(yīng)的插件來完成，使用Gulp和Grunt只是便于項目各個環(huán)節(jié)工作流程的控制。而且，這兩款工具的話題熱度和使用率遠(yuǎn)不及Webpack，Webpack雖然是近兩年才崛起的構(gòu)建工具，但目前依然成為了最流行的構(gòu)建工具之一，Vue和React兩大前端框架的Webpack Loader也是有官方或作者本人編寫的。所以，我們在講前端工程化構(gòu)建時，推薦使用Webpack這款工具。

（2）使用Babel完成JavaScript編譯

JavaScript可以說是前端最為核心的一門編程語言了，也就是我們常說的“JS”，JS本身是可以直接在瀏覽器中執(zhí)行的，那么為什么還要使用Babel再編譯一次呢？其實，這里要解釋一下，在ECMAScript2015（簡稱ES6）正式發(fā)布以后，前端工程師關(guān)注的重心就由“JS”轉(zhuǎn)向了“ES”，作為專業(yè)的前端工程師們應(yīng)該都了解，JavaScript ≠ ECMAScript。

ECMAScript是一個標(biāo)準(zhǔn)，JavaScript是對ECMAScript標(biāo)準(zhǔn)實現(xiàn)的一個子集。宿主瀏覽器的API（BOM和DOM）再加上JavaScript，就組成了我們傳統(tǒng)認(rèn)知中的JavaScript。但是隨著ECMAScript的版本不斷迭代更新，帶來的并不是開發(fā)的便利，由于瀏覽器對ECMAScript新規(guī)范的支持實現(xiàn)比較滯后，即使是目前最新版的Chrome瀏覽器也沒有完全支持ECMAScript2015（ES6）的所有規(guī)范，而且ECMAScript2017都已經(jīng)發(fā)布了，為了更好的讓新的ES規(guī)范能夠無縫銜接瀏覽器，Babel編譯JavaScript語法的作用就突顯出來了。

Babel的作用簡單來說，就是將瀏覽器未實現(xiàn)的ECMAScript規(guī)范語法轉(zhuǎn)化為可運行的低版本語法，例如將ES6的class轉(zhuǎn)化為ES5的prototype實現(xiàn)。

（3）CSS預(yù)編譯

CSS作為瀏覽器可以直接識別的樣式語言，彌補了HTML原生樣式的不足，對于早期互聯(lián)網(wǎng)開發(fā)中，樣式的要求并不復(fù)雜，僅需要少量的CSS代碼即可。但是在如今追求用戶極致體驗的潮流下，CSS的開發(fā)要求不斷提高，復(fù)雜的CSS開發(fā)變成一件非常繁瑣和痛苦的事情。最主要的原因還是受限于瀏覽器的實現(xiàn)和CSS自身的弱編程能力。

CSS預(yù)編譯器的工作原理是提供便捷的語法和特性供開發(fā)者編寫源代碼，隨后經(jīng)過專門的編譯工具將源碼轉(zhuǎn)化為CSS語法。

（4）模塊化開發(fā)

模塊化開發(fā)和組件化開發(fā)是兩個完全不同的概念，模塊化屬于架構(gòu)層面的概念，前端工程化與模塊化的關(guān)系就類似于組裝車間與零件的關(guān)系。使用模塊化開發(fā)，可以解決下面幾個問題：

避免命名沖突；便于依賴管理；利于性能優(yōu)化；提高可維護(hù)性；提高代碼可復(fù)用性；

在ES6規(guī)范發(fā)布之前，前端模塊化開發(fā)主要有三種規(guī)范，分別是：CommonJS、AMD、CMD。

CommonJS是一種只適用于JavaScript的靜態(tài)模塊化規(guī)范，適合Node.js開發(fā)，但并不適合瀏覽器環(huán)境；而AMD/CMD規(guī)范并不是完全一致的，但核心功能是統(tǒng)一的，兩個規(guī)范都重點解決了瀏覽器對前端模塊化的需求。

ES6 Module規(guī)范推出之后，前三者的模塊化規(guī)范也逐漸退出前端的歷史舞臺。ES6 Module是語言層面的規(guī)范，與應(yīng)用場景無關(guān)，所以一個不涉及運行環(huán)境API調(diào)用的模塊可以在任何場景下運行。但是目前瀏覽器還沒有完全支持這種規(guī)范，所以，要實現(xiàn)ES6 Module規(guī)范的話，還需要使用構(gòu)建工具進(jìn)行編譯。

（5）組件化開發(fā)

前面提到了，組件化和模塊化是兩個完全不同的概念，模塊化是文件層面上對代碼和資源的拆分，組件化是設(shè)計層面上對UI的拆分。從UI中拆分出來的一個結(jié)構(gòu)單元，成為UI組件，一個UI組件單元包含了HTML模板、CSS樣式、JS邏輯。在頁面的設(shè)計過程中，頁面上的每一個元素都是組件，頁面也是一個組件，只不過頁面是一個大型組件，然后這個大型組件又由多個中小型組件拼裝而成。中型組件還可以再拆分成小型組件，小型組件再拆分成DOM元素，DOM元素也屬于瀏覽器自身的組件，是組件的基本單元。這種組件化開發(fā)就是前端開發(fā)的“分治思想”。

（6）開發(fā)環(huán)境的本地服務(wù)器與Mock服務(wù)

在前端工程化開發(fā)中，通過構(gòu)建工具可以將代碼進(jìn)行編譯，然后在瀏覽器中進(jìn)行調(diào)試，但是在開發(fā)過程中源碼的每次修改都需要執(zhí)行一次構(gòu)建，構(gòu)建完成后才能在瀏覽器里運行，這對前端工程師來說無疑就是一種災(zāi)難。要完美的解決這個問題，可以使用本地服務(wù)器與構(gòu)建工具結(jié)合，對源碼進(jìn)行監(jiān)聽并在修改之后觸發(fā)動態(tài)構(gòu)建，使用自動化構(gòu)建的方式代替人工。這種動態(tài)構(gòu)建是使用本地服務(wù)器解決開發(fā)層面上的問題。

Mock服務(wù)解決的是前后端協(xié)作開發(fā)的問題，前后端開發(fā)人員提前約定好規(guī)范，前端工程師通過本地服務(wù)器提供的Mock數(shù)據(jù)接口輔助前端邏輯的編寫和功能模塊的開發(fā)。如果項目中需要服務(wù)器端渲染（SSR），本地服務(wù)器還需要具備解析HTML模板的能力，同時Mock服務(wù)提供SSR所需的初始化數(shù)據(jù)。

前端工程師可以使用本地服務(wù)器提供的Mock數(shù)據(jù)接口，在后端人員開發(fā)的同時，進(jìn)行前端邏輯的并行開發(fā)，等到后端真實接口開發(fā)完成后，將前端請求的地址從Mock服務(wù)遷移到服務(wù)器的生產(chǎn)環(huán)境即可。

（7）規(guī)范化約束

無論是服務(wù)器端開發(fā)還是前端工程化開發(fā)，規(guī)范化的約束都至關(guān)重要。開發(fā)人員在設(shè)計項目的整體架構(gòu)時，為了考慮到項目的可擴(kuò)展性、可維護(hù)性、高內(nèi)聚性等因素，會對代碼進(jìn)行封裝，使用配置化操作，為項目開發(fā)帶來便利，這必然要求業(yè)務(wù)代碼編程范式遵循既定的約束。這種約束雖然帶來了開發(fā)上的便捷，但是在一定程度上制約了代碼的可移植性。例如，在項目中使用了某個構(gòu)建工具來解決項目需求，但是如果有一天項目需要更換另一個構(gòu)建工具時，代碼中原有的構(gòu)建工具的配置會成為冗余代碼，而且不能保證這類配置不會對新構(gòu)建工具產(chǎn)生沖突。即便是沒有產(chǎn)生沖突，對代碼的性能優(yōu)化也是會帶來一定負(fù)面影響的。工程化方案作為一種服務(wù)，應(yīng)該盡量降低對項目產(chǎn)生的負(fù)面影響。這是制定編程范式約束規(guī)范時最重要的考慮因素。

（8）項目部署流程化

站在前端開發(fā)的范疇來說，項目部署是指前端開發(fā)人員將構(gòu)建產(chǎn)出的代碼包部署到測試服務(wù)器的過程，而并非是將測試完成的代碼發(fā)布到生產(chǎn)環(huán)境的過程。在部署過程中，要考慮目標(biāo)服務(wù)器、路徑信息是否與項目一一對應(yīng)，并且可供負(fù)責(zé)部署到生產(chǎn)環(huán)境的開發(fā)人員進(jìn)行配置，部署的操作流程應(yīng)盡量簡單。

在部署流程中，使用命令行取代工具執(zhí)行（例如FTP）本地部署，能夠極大的提高部署的速度和效率，但是這只是初級階段的部署流程?？紤]團(tuán)隊協(xié)作和安全方面的因素，最佳的方式應(yīng)該是搭建一個可供嚴(yán)格審查、隊列控制、操作簡化的部署平臺，并且有專人負(fù)責(zé)掌握流程進(jìn)度。雖然這種搭建部署平臺的方式在一定程度上減緩了整體的部署速度，但是加強了團(tuán)隊協(xié)作和安全保障。

4、前端工程化未來的發(fā)展如何？

目前，Web應(yīng)用開發(fā)的分工模式還處于探索期，而且從最近流行的“大前端”的趨勢來看，前端工程師的發(fā)展或許會突破Web領(lǐng)域，向多端領(lǐng)域發(fā)展，例如React Native、Weex、Electron、小程序等。從誕生之初“切圖仔”到大前端概念，前端工程師的定位和負(fù)責(zé)的技術(shù)范疇一直在變化，但是前端工程師產(chǎn)出的服務(wù)對象永遠(yuǎn)是用戶。在Node.js之前，瀏覽器是前端工程師生存的“一畝三分地”，Node.js的出現(xiàn)打破了這個局面，以致出現(xiàn)了“大前端”的發(fā)展趨勢。

Node.js中間層+瀏覽器是目前實現(xiàn)“大前端”的基本模式，前端工程師掌握著與用戶相關(guān)的所有資源，能夠全面地掌握開發(fā)進(jìn)度以及實現(xiàn)更合理的前后端分離方案。這種模式讓前端工程師突破瀏覽器的瓶頸，邁向Web應(yīng)用層面，這也是未來前端發(fā)展的主流趨勢。

無論是專注于瀏覽器，還是兼顧了Node.js中間層，前端工程師的利劍始終指向的是面向瀏覽器的Web領(lǐng)域，前端工程化所提供的是一種服務(wù)，服務(wù)對象是不斷參與到項目迭代過程中的前端開發(fā)人員，服務(wù)的內(nèi)容涉及到開發(fā)、構(gòu)建、部署等各個環(huán)節(jié)。

前端工程師在未來的定位必然會發(fā)生變化，但是前端工程化唯一不變的原則是始終以前端開發(fā)為中心，前端工程化沒有統(tǒng)一的行業(yè)標(biāo)準(zhǔn)，也沒有固定的形態(tài)，更沒有最合理的方案，只要前端工程師的定位還在不斷的變化，前端工程化的進(jìn)程將會一直持續(xù)下去。