【話題】什麼是前端工程化？

雖然前端工程化的概念興起還沒幾年的時間，但是對于“工程化”這個詞并不是一個新鮮詞了，在其他軟體開發的領域很早就已經有了高度的工程化，例如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領域，前端工程化所提供的是一種服務，服務對象是不斷參與到項目疊代過程中的前端開發人員，服務的内容涉及到開發、建構、部署等各個環節。

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