市場(chǎng)需求和技術(shù)的發(fā)展在不斷地改變Web產(chǎn)品形態(tài)，在前端網(wǎng)站制作工程師的工作內(nèi)容不斷變化的過程中，前端工程化的形態(tài)也一直都在變化著。
1.混沌形態(tài)
我們不妨將這種“前端寫demo，后端寫邏輯、套模板”的開發(fā)模式稱為“混沌形態(tài)”。這種形態(tài)的時(shí)代背景是Web產(chǎn)品的邏輯和交互普遍比較簡(jiǎn)單，前端工程師這一專業(yè)崗位剛剛興起，但是負(fù)責(zé)的工作僅僅是樣式以及部分動(dòng)畫邏輯。前端工程師與后端工程師之間的協(xié)作是串行的，如圖1所示。
圖1 混沌形態(tài)前端工程師與后端工程師之間的協(xié)作
混沌形態(tài)下前端工程師的產(chǎn)出資源除了CSS外，均需要后端工程師進(jìn)行二次處理后才會(huì)上線，甚至有時(shí)候連CSS都需要二次處理，比如行內(nèi)樣式。這種形態(tài)下是沒有前端工程化可言的。
2.前后端分離形態(tài)
催動(dòng)前端開發(fā)第一次進(jìn)化的關(guān)鍵技術(shù)是AJAX。AJAX技術(shù)的問世不僅改變了Web頁(yè)面的交互模式，也間接提高了用戶對(duì)Web產(chǎn)品的需求，從而促進(jìn)了前端邏輯的不斷復(fù)雜化。服務(wù)器端工程師負(fù)責(zé)前端邏輯開發(fā)的混沌形態(tài)被打破，因?yàn)榉?wù)器端邏輯本身便具備高度的復(fù)雜度，再加上復(fù)雜的前端邏輯，自然不堪重負(fù)。所以，工程師開始思考改變?cè)械姆止つＪ剑呵岸诉壿?、樣式和HTML全部交由前端工程師開發(fā)。這是催生前端工程化萌芽的關(guān)鍵一步，此時(shí)的協(xié)作流程如圖2所示。
圖2 前后端分離形態(tài)協(xié)作流程
在這種分工模式下，省去了后端工程師對(duì)JavaScript代碼的整合以及對(duì)CSS代碼的二次處理工作，從一定程度上提升了維護(hù)和迭代的工作效率。但是因?yàn)殪o態(tài)資源與動(dòng)態(tài)資源一同部署，所以仍然難以避免必要的人工交付流程。
我們?cè)O(shè)想一下將這種分工模式帶入當(dāng)前時(shí)間節(jié)點(diǎn)，這時(shí)開發(fā)過程中會(huì)遇到哪些問題。
1）我們想使用最新的ECMAScript規(guī)范進(jìn)行開發(fā)，但是受限于瀏覽器實(shí)現(xiàn)不理想，上線前需要使用特殊工具轉(zhuǎn)譯為瀏覽器支持的語(yǔ)法。
2）我們受夠了CSS的弱編程能力，想使用LESS/SASS等預(yù)編譯語(yǔ)法或者PostCSS自動(dòng)處理hack。但是瀏覽器不支持，上線前需要使用特殊工具進(jìn)行編譯轉(zhuǎn)換。
3）本地開發(fā)環(huán)境下靜態(tài)資源的引用URL都是本地相對(duì)地址，上線前要修改為真實(shí)的URL。手動(dòng)修改非常煩瑣，需要借助工具完成。這種功能通常被稱為資源定位。
4）考慮產(chǎn)品的性能，上線前需要將JS、CSS、圖片等資源進(jìn)行壓縮，需要使用CSS Sprites，甚至需要將小體積圖片通過base64格式內(nèi)嵌，這些都需要借助于工具實(shí)現(xiàn)。
5）模塊化開發(fā)能夠提高Web產(chǎn)品的性能和源代碼的維護(hù)效率，散列的模塊在上線前需要進(jìn)行依賴分析與合并打包，需要借助于工具實(shí)現(xiàn)。
6）編寫JavaScript邏輯代碼時(shí)如果需要與數(shù)據(jù)接口交互，則依賴于服務(wù)器端接口API的完成進(jìn)度。
7）靜態(tài)文件（JS、CSS、圖片等）與動(dòng)態(tài)文件（HTML模板）仍然存在于同一項(xiàng)目中，所以前端工程師產(chǎn)出的文件仍然需要服務(wù)
器端工程師進(jìn)行部署。
此處列出的只是一些比較典型的問題，并未覆蓋前后端開發(fā)以及協(xié)作過程中的全部問題。
將上述問題進(jìn)一步劃分：前5條因?yàn)椴淮嬖谇昂蠖说鸟詈?，可以歸類為前端開發(fā)層面的問題；第6條屬于前后端協(xié)作的問題；第7條屬于部署的問題。細(xì)化分類后的問題列表如下。
·開發(fā)層面
1.ES規(guī)范與瀏覽器兼容性不一致。
2.CSS的弱編程能力。
3.資源定位。
4.圖片壓縮/base64內(nèi)嵌/CSS Sprites。
5.模塊依賴分析和壓縮打包。
·協(xié)作層面
JavaScript部分邏輯依賴接口API。
·部署層面
部分資源需要借助后端工程師部署。
筆者相信大多數(shù)一線開發(fā)者最迫切要解決的問題普遍集中在開發(fā)層面。在開發(fā)層面問題的描述中反復(fù)提到一個(gè)詞——工具。開發(fā)者采用各種各樣的專業(yè)工具解決對(duì)應(yīng)的需求，比如使用Babe1進(jìn)行ES規(guī)范的轉(zhuǎn)譯、使用LESS/SASS編譯工具進(jìn)行預(yù)編譯語(yǔ)法轉(zhuǎn)譯、使用r.js解決AMD模塊的壓縮打包等。將所有工具的功能進(jìn)行整合并統(tǒng)一為規(guī)范的工具棧（請(qǐng)注意不是將工具整合，而是將功能整合），這就是前端工程化的第一步：構(gòu)建。
第一步：加入構(gòu)建流程
引入構(gòu)建后的工作流程如圖3所示。
圖3 引入構(gòu)建后的工作流程
構(gòu)建流程可以確保前端工程師能夠使用有助于提高開發(fā)和維護(hù)效率的框架、規(guī)范進(jìn)行源代碼的編寫，比如使用ECMAScript 6/7規(guī)范編寫JavaScript、使用LESS/SASS等預(yù)編譯工具編寫Style、使用AMD/CommonJS等模塊化方案進(jìn)行模塊化開發(fā)等。此外，構(gòu)建還
具備圖片壓縮、自動(dòng)生成CSSSprites等功能，進(jìn)一步減少了煩瑣的人工操作。
前端工程化進(jìn)化到第一步后解決了開發(fā)層面的問題，會(huì)提高前端工程師的開發(fā)效率，但是仍未觸及協(xié)作以及部署層面。
·開發(fā)層面
√ES規(guī)范與瀏覽器兼容性不一致。
√CSS的弱編程能力。
√資源定位。
√圖片壓縮/base64內(nèi)嵌/CSS Sprites。
√模塊依賴分析和壓縮打包。
·協(xié)作層面
XJavaScript部分邏輯依賴接口API。
·部署層面
X部分資源需要借助后端工程師部署。
構(gòu)建流程的加入提高了前端工程師單方面的工作效率，下一步是思考如何提高整體團(tuán)隊(duì)的效率，也就是在前后端協(xié)作開發(fā)過程中遇到的問題。最典型的就是前端邏輯依賴后端接口的實(shí)現(xiàn)進(jìn)度，這種串行的工作流程對(duì)于開發(fā)進(jìn)度的影響是非常大的。所以，接下來首當(dāng)其沖的便是解決前后端工程師并行開發(fā)的問題。
第二步：加入本地開發(fā)服務(wù)器
本地開發(fā)服務(wù)器并不是工具，而是一個(gè)真正意義上的Web服務(wù)。本地服務(wù)器最典型的應(yīng)用是Mock服務(wù)，通過提供模擬接口和數(shù)據(jù)解決前端JavaScript對(duì)數(shù)據(jù)API的依賴問題，從而實(shí)現(xiàn)前后端并行開發(fā)，前提是前后端工程師在進(jìn)入開發(fā)階段之前需要協(xié)商制定接口API的詳細(xì)規(guī)范。
對(duì)于一些有云Mock服務(wù)器的團(tuán)隊(duì)來講，本地服務(wù)器甚至可以不提供Mock服務(wù)。但是如果項(xiàng)目需要SSR（Server Side Render，服務(wù)器端渲染）并且本地服務(wù)器與服務(wù)器端使用相同的編程語(yǔ)言，本地服務(wù)器還應(yīng)該具備HTML模板解析功能。這樣，前端工程師負(fù)責(zé)View層的開發(fā)工作，后端工程師負(fù)責(zé)服務(wù)器端邏輯開發(fā)。這種模式對(duì)Mock服務(wù)有了額外的需求——提供服務(wù)器端渲染的頁(yè)面初始數(shù)據(jù)。云Mock平臺(tái)是無法完成此項(xiàng)功能的，這是本地Mock服務(wù)獨(dú)有的優(yōu)勢(shì)。所以，不論項(xiàng)目是否需要SSR，我們都建議將Mock服務(wù)集成到本地開發(fā)服務(wù)器。即使你的團(tuán)隊(duì)有云Mock服務(wù)，本地的Mock服務(wù)也可以使用代理模式將請(qǐng)求轉(zhuǎn)交給云Mock服務(wù)。
由于所有的客戶端相關(guān)資源（包括Views)均交由前端工程師負(fù)責(zé)開發(fā)，后端工程師不需要對(duì)前端工程師產(chǎn)出的文件進(jìn)行二次處理，只進(jìn)行一次支付便可部署，因此可以使用Git、SVN等版本管理工具替代人工交付，對(duì)代碼回滾提供了更嚴(yán)謹(jǐn)?shù)募夹g(shù)支持。
此外，本地服務(wù)器與構(gòu)建功能相結(jié)合，可以提供動(dòng)態(tài)構(gòu)建、瀏覽器自動(dòng)刷新等功能，這進(jìn)一步提高了前端工程師的工作效率。
綜上所述，本地服務(wù)器須具備以下功能。
·Mock服務(wù)。如果團(tuán)隊(duì)具備統(tǒng)一的云Mock平臺(tái)，本地服務(wù)器可以不提供Mock服務(wù)。但如果需要支持SSR，則必須提供本地Mock服務(wù)。
·支持SSR，前提是本地服務(wù)器與線上服務(wù)器使用相同的編程語(yǔ)言。
·動(dòng)態(tài)構(gòu)建，瀏覽器自動(dòng)刷新。
引入本地服務(wù)器后的開發(fā)流程如圖4所示。
圖4 引入本地服務(wù)器后的開發(fā)流程
加入本地服務(wù)器后的問題情況如下。
·開發(fā)層面
√ES規(guī)范與瀏覽器兼容性不一致。
√CSS的弱編程能力。
.資源定位。
√圖片壓縮/base64內(nèi)嵌/CSS Sprites。
√模塊依賴分析和壓縮打包。
·協(xié)作層面
√JavaScript部分邏輯依賴接口API。
·部署層面
X部分資源需要借助后端工程師部署。
前端工程化發(fā)展到這個(gè)階段，我們解決了開發(fā)以及協(xié)作層面的問題，留到最后的只有部署了。
第三步：靜態(tài)資源和動(dòng)態(tài)資源分離部署
我們?cè)O(shè)想一下這種場(chǎng)景：前端代碼中出現(xiàn)了Bug，前端工程師修復(fù)后仍需要麻煩后端工程師進(jìn)行部署。前端的Bug有時(shí)候可以細(xì)微到像素級(jí)別，即使再小的Bug也需要調(diào)動(dòng)前后端工程師來修復(fù)，這樣的工作效率是非常低下的。所以優(yōu)化部署的基本原則是，確保單方問題的修復(fù)不需要調(diào)動(dòng)多方資源。具體的解決方案就是靜態(tài)資源與動(dòng)態(tài)資源分離部署。動(dòng)靜態(tài)資源的分離部署可以解耦前后端工程師的部署行為，兩者可以對(duì)自身的產(chǎn)出進(jìn)行獨(dú)立部署。減少了耦合工作，就提高了迭代和維護(hù)效率。同時(shí)，動(dòng)靜態(tài)資源分離部署也是Web應(yīng)用架構(gòu)優(yōu)化的一個(gè)必要策略。
分離部署對(duì)工作效率的提升主要體現(xiàn)在集成測(cè)試階段。比如測(cè)試人員發(fā)現(xiàn)瀏覽器有樣式Bug，在前端工程師修復(fù)并將CSS文件部署到測(cè)試文件服務(wù)器后便可以立即進(jìn)行Bug修復(fù)驗(yàn)證測(cè)試，不涉及后端工程師的工作。前提是測(cè)試所用的靜態(tài)資源服務(wù)器需要設(shè)置瀏覽器不使用緩存或者協(xié)商緩存策略，并且靜態(tài)資源的URL不添加版本號(hào)參數(shù)或者h(yuǎn)ash文件指紋，這樣在靜態(tài)文件更新后刷新瀏覽器即可請(qǐng)求到最新的文件，無須清理瀏覽器緩存。同理，只涉及服務(wù)器端代碼的Bug修復(fù)也不涉及前端工程師的工作。
我們不妨再激進(jìn)一點(diǎn)：將渲染TL的工作全部交給前端，也就是目前業(yè)界流行的SPA（單頁(yè)應(yīng)用）。前端渲染的優(yōu)點(diǎn)如下。
·前端掌控路由，與傳統(tǒng)的服務(wù)器端路由相比用戶體驗(yàn)更佳。
·可移植、可離線使用。
·服務(wù)器端提供的是干凈的數(shù)據(jù)接口，具備高度的可復(fù)用性。
·HIML資源作為靜態(tài)資源，易于部署。
·前端工程師與后端工程師可以使用Git、SVN等工具分別維護(hù)獨(dú)立的源代碼，無須耦合。
前端渲染的缺點(diǎn)是不利于SEO（搜索引擎優(yōu)化）。Google搜索爬蟲制定了針對(duì)單頁(yè)應(yīng)用的優(yōu)化規(guī)范，國(guó)內(nèi)的搜索引擎目前暫未提供類似規(guī)范。即便如此，SPA仍然在業(yè)界被廣泛使用，其主要原因是Web產(chǎn)品已經(jīng)改變了原有的形態(tài)。自身功能和宿主瀏覽器的不斷增強(qiáng)讓W(xué)eb產(chǎn)品越來越接近原生應(yīng)用，對(duì)SE0不像以前那般依賴。另外，越來越多的Hybrid（混合）應(yīng)用占據(jù)了APP市場(chǎng)，由WebView
承載的Web產(chǎn)品更是無須考慮SEO問題。
在上一階段的前端工程化基礎(chǔ)上，加入靜態(tài)資源與動(dòng)態(tài)資源分離部署功能后的前后端協(xié)作流程如圖5所示。
圖5 前后端協(xié)作流程
加入靜態(tài)資源與動(dòng)態(tài)資源分離部署功能后，一方面提高了部署的效率，另一方面也提高了Bug的修復(fù)效率。需要注意的一點(diǎn)是，文件必須使用協(xié)商緩存策略，便于線上資源的及時(shí)更新。
·開發(fā)層面
√ES規(guī)范與瀏覽器兼容性不一致。
√CSS的弱編程能力。
√資源定位。
√圖片壓縮/base64內(nèi)嵌/CSS Sprites。
√模塊依賴分析和壓縮打包。
·協(xié)作層面
√JavaScript部分邏輯依賴接口API。
·部署層面
√部分資源需要借助后端工程師部署。
前端工程化發(fā)展到這一階段，所對(duì)應(yīng)的前后端分離工作模式是目前國(guó)內(nèi)絕大部分團(tuán)隊(duì)所采用的。本書所討論的前端工程化解決方案便是針對(duì)這種模式搭建的。
這種模式下的前后端分離并非完美，前后端網(wǎng)站制作工程師的分工也并非最合理，此階段的前端工程化并非最終形態(tài)。我們將在以后深入討論前端工程化的理想模式。
今天的網(wǎng)頁(yè)制作分享就到這了，如果您喜歡這篇文章，您可以分享給你的朋友！深圳網(wǎng)站建設(shè)-博納網(wǎng)絡(luò)編輯整理。
