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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）使用Webpack實(shí)現項目構建

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

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

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

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

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

（2）使用Babel完成JavaScript編譯

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

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

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

（3）CSS預編譯

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

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

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

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

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

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

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

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

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

前面提到了，組件化和模塊化是兩個(gè)完全不同的概念，模塊化是文件層面上對代碼和資源的拆分，組件化是設計層面上對UI的拆分。從UI中拆分出來(lái)的一個(gè)結構單元，成為UI組件，一個(gè)UI組件單元包含了HTML模板、CSS樣式、JS邏輯。在頁(yè)面的設計過(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ò)構建工具可以將代碼進(jìn)行編譯，然后在瀏覽器中進(jìn)行調試，但是在開(kāi)發(fā)過(guò)程中源碼的每次修改都需要執行一次構建，構建完成后才能在瀏覽器里運行，這對前端工程師來(lái)說(shuō)無(wú)疑就是一種災難。要完美的解決這個(gè)問(wèn)題，可以使用本地服務(wù)器與構建工具結合，對源碼進(jìn)行監聽(tīng)并在修改之后觸發(fā)動(dòng)態(tài)構建，使用自動(dòng)化構建的方式代替人工。這種動(dòng)態(tài)構建是使用本地服務(wù)器解決開(kāi)發(fā)層面上的問(wèn)題。

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

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

（7）規范化約束

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

（8）項目部署流程化

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

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

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

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

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

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

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