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

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

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

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

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

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

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

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

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

      3、如何實(shí)施前端工程化？

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

      靜態(tài)資源和動(dòng)態(tài)資源的處理；

      JavaScript實(shí)現(xiàn)前端業(yè)務(wù)邏輯；

      HTML模板文件的產(chǎn)出；

      中間層Web服務(wù)，一般由Node.js實(shí)現(xiàn)；

      前端單元測(cè)試；

      前端項(xiàng)目部署；

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

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

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

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

      無(wú)法被瀏覽器直接識(shí)別的JS代碼，包括ES6/7/8/9/10等符合ECMAScript規(guī)范的JS代碼；

      無(wú)法被瀏覽器直接識(shí)別的CSS代碼，包括SASS/LESS等預(yù)編譯的CSS語(yǔ)法；

      無(wú)法被瀏覽器識(shí)別的HTML模板代碼，包括jade、ejs、artTemplate、mustache等Node.js模板引擎；

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

      依賴打包，將同步依賴的文件打包在一起，減少HTTP請(qǐng)求數(shù)量；

      資源嵌入，例如將小于10kb的圖片編譯為base64格式嵌入文檔，減少HTTP請(qǐng)求；

      文件壓縮，減少文件體積，縮短請(qǐng)求時(shí)間；

      為文件加入hash指紋，以應(yīng)對(duì)瀏覽器緩存策略；

      將開(kāi)發(fā)環(huán)境下的域名與靜態(tài)資源文件路徑修改為生產(chǎn)環(huán)境下的域名和路徑；

      文件名稱的改變；

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

      （2）使用Babel完成JavaScript編譯

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

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

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

      （3）CSS預(yù)編譯

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

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

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

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

      避免命名沖突；

      便于依賴管理；

      利于性能優(yōu)化；

      提高可維護(hù)性；

      提高代碼可復(fù)用性；

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

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

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

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

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

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

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

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

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

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

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

      （8）項(xiàng)目部署流程化

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

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

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

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

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

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

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

      最后歡迎大家添加我們的web前端技術(shù)分享交流qq群：791201477  加群找群管理要免費(fèi)的學(xué)習(xí)資料和項(xiàng)目代碼，歡迎大家進(jìn)群交流~~~