DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> WEB網站前端 >> WEB前端代碼 >> 從零打造前端工程體系-淺析前端工程化
從零打造前端工程體系-淺析前端工程化
編輯:WEB前端代碼     

1. 什麼是前段工程化

自有前端工程師這個稱謂以來,前端的發展可謂是日新月異。相比較已經非常成熟的其他領域,前端雖是後起之秀,但其野蠻生長是其他領域不能比的。雖然前端技術飛快發展,但是前端整體的工程生態並沒有同步跟進。目前絕大多數的前端團隊仍然使用非常原始的“切圖(FE)->套模板(RD)”的開發模式,這種模式下的前端開發雖說不是刀耕火種的原始狀態,但是效率非常低下。

前端的工程化問題與傳統的軟件工程雖然有所不同,但是面臨的問題是一樣的。我們首先回顧一下傳統的軟件開發流程模型:

上圖中的運行和維護並不是串行關系,也並非絕對的並行關系。維護貫穿從編碼到運行的整個流程。

如果說計算機科學要解決的是系統的某個具體問題,或者更通俗點說是面向編碼的,那麼工程化要解決的是如何提高整個系統生產效率。所以,與其說軟件工程是一門科學,不如說它更偏向於管理學和方法論。

軟件工程是個很寬泛的話題,每個人都有自己的理解。以上是筆者個人的理解,僅供參考。

具體到前端工程化,面臨的問題是如何提高編碼->測試->維護階段的生產效率。

可能會有人認為應該包括需求分析和設計階段,上圖展示的軟件開發模型中,這兩個階段具體到前端開發領域,更恰當的稱謂應該是功能需求分析UI設計,分別由產品經理和UI工程師完成。至於API需求分析和API設計,應該包括在編碼階段。

2. 前端工程化面臨的問題

要解決前端工程化的問題,可以從兩個角度入手:開發部署

從開發角度,要解決的問題包括:

  1. 提高開發生產效率;
  2. 降低維護難度。

這兩個問題的解決方案有兩點:

  1. 制定開發規范,提高團隊協作能力;
  2. 分治。軟件工程中有個很重要的概念叫做模塊化開發其中心思想就是分治。

從部署角度,要解決的問題主要是資源管理,包括:

  1. 代碼審查;
  2. 壓縮打包;
  3. 增量更新;
  4. 單元測試;

要解決上述問題,需要引入構建/編譯階段。

2.1 開發規范

開發規范的目的是統一團隊成員的編碼規范,便於團隊協作和代碼維護。開發規范沒有統一的標准,每個團隊可以建立自己的一套規范體系。

值得一提的是JavaScript的開發規范,尤其是在ES2015越來越普及的局面下,保持良好的編碼風格是非常必要的。筆者推薦Airbnb的eslint規范。

2.2 模塊/組件化開發

2.2.1 模塊還是組件?

很多人會混淆模塊化開發和組件化開發。但是嚴格來講,組件(component)和模塊(module)應該是兩個不同的概念。兩者的區別主要在顆粒度方面。《Documenting Software Architectures》一書中對於component和module的解釋如下:

A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.

In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.

簡單講,module側重的是對屬性的封裝,重心是在設計和開發階段,不關注runtime的邏輯。module是一個白盒;而component是一個可以獨立部署的軟件單元,面向的是runtime,側重於產品的功能性。component是一個黑盒,內部的邏輯是不可見的。

用通俗的話講,模塊可以理解為零件,比如輪胎上的螺絲釘;而組件則是輪胎,是具備某項完整功能的一個整體。具體到前端領域,一個button是一個模塊,一個包括多個button的nav是一個組件。

模塊和組件的爭論由來已久,甚至某些編程語言對兩者的實現都模糊不清。前端領域也是如此,使用過bower的同行知道bower安裝的第三方依賴目錄是bower_component;而npm安裝的目錄是node_modules。也沒必要為了這個爭得頭破血流,一個團隊只要統一思想,保證開發效率就可以了。至於是命名為module還是component都無所謂。

筆者個人傾向組件黑盒、模塊白盒這種思想。

2.2.2 模塊/組件化開發的必要性

隨著web應用規模越來越大,模塊/組件化開發的需求就顯得越來越迫切。模塊/組件化開發的核心思想是分治,主要針對的是開發和維護階段。

關於組件化開發的討論和實踐,業界有很多同行做了非常詳細的介紹,本文的重點並非關注組件化開發的詳細方案,便不再贅述了。筆者收集了一些資料可供參考:

  1. Web應用的組件化開發;
  2. 前端組件化開發實踐;
  3. 大規模的前端組件化與模塊化。

3. 構建&編譯

嚴謹地講,構建(build)編譯(compile)是完全不一樣的兩個概念。兩者的顆粒度不同,compile面對的是單文件的編譯,build是建立在compile的基礎上,對全部文件進行編譯。在很多Java IDE中還有另外一個概念:make。make也是建立在compile的基礎上,但是只會編譯有改動的文件,以提高生產效率。本文不探討build、compile、make的深層運行機制,下文所述的前段工程化中構建&編譯階段簡稱為構建階段

3.1 構建在前端工程中的角色

在討論具體如何組織構建任務之前,我們首先探討一下在整個前端工程系統中,構建階段扮演的是什麼角色。

首先,我們看看目前這個時間點(2016年),一個典型的web前後端協作模式是什麼樣的。請看下圖:

上圖是一個比較成熟的前後端協作體系。當然,目前由於Node.js的流行開始普及大前端的概念,稍後會講述。

自Node.js問世以來,前端圈子一直傳播著一個詞:顛覆。前端工程師要借助Node.js顛覆以往的web開發模式,簡單說就是用Node.js取代php、ruby、python等語言搭建web server,在這個顛覆運動中,JavaScript是前端工程師的信心源泉。我們不討論Node.js與php們的對比,只在可行性這個角度來講,大前端這個方向吸引越來越多的前端工程師。

其實大前端也可以理解為全棧工程師,全棧的概念與編程語言沒有相關性,核心的競爭力是對整個web產品從前到後的理解和掌握。

那麼在大前端模式下,構建又是扮演什麼角色呢?請看下圖:

大前端體系下,前端開發人員掌握著Node.js搭建的web server層。與上文提到的常規前端開發體系下相比,省略了mock server的角色,但是構建在大前端體系下的作用並沒有發生改變。也就是說,不論是大前端還是“小”前端,構建階段在兩種模式下的作用完全一致,構建的作用就是對靜態資源以及模板進行處理,換句話說:構建的核心是資源管理

3.2 資源管理要做什麼?

前端的資源可以分為靜態資源模板。模板對靜態資源是引用關系,兩者相輔相成,構建過程中需要對兩種資源使用不同的構建策略。

目前仍然有大多數公司將模板交由後端開發人員控制,前端人員寫好demo交給後端程序員“套模板”。這種協作模式效率是非常低的,模板層交由前端開發人員負責能夠很大程度上提高工作效率。

3.2.1 靜態資源構建策略

靜態資源包括js、css、圖片等文件,目前隨著一些新規范和css預編譯器的普及,通常開發階段的靜態資源是:

  1. es6/7規范的文件;
  2. less/sass等文件(具體看團隊技術選型);
  3. [可選]獨立的小圖標,在構建階段使用工具處理成spirit圖片。

構建階段在處理這些靜態文件時,基本的功能應包括:

  1. es6/7轉譯,比如babel;
  2. 將less/sass編譯成css;
  3. spirit圖片生成;

以上提到的幾個功能可以說是為了彌補浏覽器自身功能的缺陷,也可以理解為面向語言本身的,我們可以將這些功能統稱為預編譯

除了語言本身,靜態資源的構建處理還需要考慮web應用的性能因素。比如開發階段使用組件化開發模式,每個組件有獨立的js/css/圖片等文件,如果不做處理每個文件獨立上線的話,無疑會增加http請求的數量,從而影響web應用的性能表現。針對諸如此類的問題,構建階段需要包括以下功能:

  1. 依賴打包。分析文件依賴關系,將同步依賴的的文件打包在一起,減少http請求數量;
  2. 資源嵌入。比如小於10KB的圖片編譯為base64格式嵌入文檔,減少一次http請求;
  3. 文件壓縮。減小文件體積;
  4. hash指紋。通過給文件名加入hash指紋,以應對浏覽器緩存引起的靜態資源更新問題;
  5. 代碼審查。避免上線文件的低級錯誤;

以上幾個功能除了壓縮是完全自動化的,其他兩個功能都需要人工的配置。比如為了提升首屏渲染性能,開發人員在開發階段需要盡量減少同步依賴文件的數量。

以上提到的所有功能可以理解為工具層面的構建功能。

以上提到的構建功能只是構建工具的基本功能。如果停留在這個階段,那麼也算是個及格的構建工具了,但也僅僅停留在工具層面。對比目前較流行的一些構建產品,比如fis,它具備以上所得的編譯功能,同時提供了一些機制以提高開發階段的生產效率。包括:

  1. 文件監聽。配合動態構建、浏覽器自動刷新等功能,提高開發效率;
  2. mock server。並非所有前端團隊都是大前端(事實上很少團隊是大前端),即使在大前端體系下,mock server的存在也是很有必要的;

我們也可以將上面提到的功能理解為平台層面的構建功能。

3.2.2 模板的構建策略

模板與靜態資源是容器-模塊關系。模板直接引用靜態資源,經過構建後,靜態資源的改動有以下幾點:

  1. url改變。開發環境與線上環境的url肯定是不同的,不同類型的資源甚至根據項目的CDN策略放在不同的服務器上;
  2. 文件名改變。靜態資源經過構建之後,文件名被加上hash指紋,內容的改動導致hash指紋的改變。

其實url包括文件名的改動,之所以將兩者分開論述是為了讓讀者區分CDN與構建對資源的不同影響。

對於模板的構建宗旨是在靜態資源url和文件名改變後,同步更新模板中資源的引用地址

現在有種論調是脫離模板的依賴,html由客戶端模板引擎渲染,簡單說就是文檔內容由JavaScript生成,服務端模板只提供一個空殼子和基礎的靜態資源引用。這種模式越來越普遍,一些較成熟的框架也驅動了這個模式的發展,比如React、Vue等。但目前大多數web產品為了提高首屏的性能表現,仍然無法脫離對服務端渲染的依賴。所以對模板的構建處理仍然很有必要性。

具體的構建策略根據每個團隊的情況有所差異,比如有些團隊中模板由後端工程師負責,這種模式下fis的資源映射表機制是非常好的解決方案。本文不討論具體的構建策略,後續文章會詳細講述。

模板的構建是工具層面的功能。

3.2.3 小結

構建可以分為工具層面平台層面的功能:

  • 工具層面
  1. 預編譯,包括es6/7語法轉譯、css預編譯器處理、spirit圖片生成;
  2. 依賴打包;
  3. 資源嵌入;
  4. 文件壓縮;
  5. hash指紋;
  6. 代碼審查;
  7. 模板構建。
  • 平台層面
  1. 文件監聽,動態編譯;
  2. mock server。

4. 總結

一個完整的前端工程體系應該包括:

  1. 統一的開發規范;
  2. 組件化開發;
  3. 構建流程。

開發規范和組件化開發面向的開發階段,宗旨是提高團隊協作能力,提高開發效率並降低維護成本。

構建工具和平台解決了web產品一系列的工程問題,旨在提高web產品的性能表現,提高開發效率。

隨著Node.js的流行,對於前端的定義越來越寬泛,在整個web開發體系中。前端工程師的角色越來越重要。本文論述的前端工程體系沒有涉及Node.js這一層面,當一個團隊步入大前端時代,前端的定義已經不僅僅是“前端”了,我想Web工程師這個稱號更合適一些。

之前跟一位前端架構師討論構建中對於模塊化的處理時,他提到一個很有意思的觀點:所謂的壓縮打包等為了性能做出的構建,其實是受限於客戶端本身。試想,如果未來的浏覽器支持大規模並發請求、網絡延遲小到微不足道,我們還需要壓縮打包嗎?

誠然,任何架構也好,策略也好,都是對當前的一種解決方案,並不是一條條鐵律。脫離了時代,任何技術討論都沒有意義。

參考資料

  1. 前端工程-基礎篇;
  2. 前端開發體系建設日記;
  3. 前端工程與性能優化;
  4. 如何高效地管理網站靜態資源;
XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved