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

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

　　在回答前端工程化這個問題之前，我們應該先考慮另外一個問題：前端開發中會不會涉及到業務?再詳細一點，就是前端工程師到底需不需要了解服務端的業務邏輯，再或者說，要不要將一部分服務端的業務邏輯放到前端來實現。這個問題沒有標準的答案，實際上應該屬于工程協作問題，就是誰該干什么的問題。

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

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

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

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

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

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

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

　　明確前后端開發的分工，是實現前后端分離的第一步，也是后面實現前端各種優化方案的基礎。前端工程師主要負責的內容包括：

　　靜態資源和動態資源的處理;

　　JavaScript實現前端業務邏輯;

　　HTML模板文件的產出;

　　中間層Web服務，一般由Node.js實現;

　　前端單元測試;

　　前端項目部署;

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

　　從項目開發的整體環節來說，實現前端工程化還需要熟練掌握下面幾個方面：

　　(1)使用Webpack實現項目構建

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

　　無法被瀏覽器直接識別的JS代碼，包括ES6/7/8/9/10等符合ECMAScript規范的JS代碼;

　　無法被瀏覽器直接識別的CSS代碼，包括SASS/LESS等預編譯的CSS語法;

　　無法被瀏覽器識別的HTML模板代碼，包括jade、ejs、artTemplate、mustache等Node.js模板引擎;

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

　　依賴打包，將同步依賴的文件打包在一起，減少HTTP請求數量;

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

　　文件壓縮，減少文件體積，縮短請求時間;

　　為文件加入hash指紋，以應對瀏覽器緩存策略;

　　將開發環境下的域名與靜態資源文件路徑修改為生產環境下的域名和路徑;

　　文件名稱的改變;

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

　　(2)使用Babel完成JavaScript編譯

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

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

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

　　(3)CSS預編譯

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

　　CSS預編譯器的工作原理是提供便捷的語法和特性供開發者編寫源代碼，隨后經過專門的編譯工具將源碼轉化為CSS語法。

　　(4)模塊化開發

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

　　避免命名沖突;

　　便于依賴管理;

　　利于性能優化;

　　提高可維護性;

　　提高代碼可復用性;

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

　　CommonJS是一種只適用于JavaScript的靜態模塊化規范，適合Node.js開發，但并不適合瀏覽器環境;而AMD/CMD規范并不是完全一致的，但核心功能是統一的，兩個規范都重點解決了瀏覽器對前端模塊化的需求。

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

　　(5)組件化開發

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

　　(6)開發環境的本地服務器與Mock服務

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

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

　　前端工程師可以使用本地服務器提供的Mock數據接口，在后端人員開發的同時，進行前端邏輯的并行開發，等到后端真實接口開發完成后，將前端請求的地址從Mock服務遷移到服務器的生產環境即可。

　　(7)規范化約束

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

　　(8)項目部署流程化

　　站在前端開發的范疇來說，項目部署是指前端開發人員將構建產出的代碼包部署到測試服務器的過程，而并非是將測試完成的代碼發布到生產環境的過程。在部署過程中，要考慮目標服務器、路徑信息是否與項目一一對應，并且可供負責部署到生產環境的開發人員進行配置，部署的操作流程應盡量簡單。

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

　　4、前端工程化未來的發展如何?

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

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

　　無論是專注于瀏覽器，還是兼顧了Node.js中間層，前端工程師的利劍始終指向的是面向瀏覽器的Web領域，前端工程化所提供的是一種服務，服務對象是不斷參與到項目迭代過程中的前端開發人員，服務的內容涉及到開發、構建、部署等各個環節。

　　前端工程師在未來的定位必然會發生變化，但是前端工程化唯一不變的原則是始終以前端開發為中心，前端工程化沒有統一的行業標準，也沒有固定的形態，更沒有最合理的方案，只要前端工程師的定位還在不斷的變化，前端工程化的進程將會一直持續下去。

　　更多關于html5培訓的問題，歡迎咨詢千鋒教育在線名師，如果想要了解我們的師資、課程、項目實操的話可以點擊咨詢課程顧問，獲取試聽資格來試聽我們的課程，在線零距離接觸千鋒教育大咖名師，讓你輕松從入門到精通。