前端工程化彙總

隨着前段項目的日益複雜，前段有必要進行工程化。前段工程化主要包括4個方面：模塊化、組件化、規範化和自動化。

1、模塊化
背景：瀏覽器自己並不提供模塊管理的機制，爲了調用各個模塊，有時不得不在網頁中，加入一大堆script標籤。這樣就使得網頁體積臃腫，難以維護，還產生大量的HTTP請求，拖慢顯示速度，影響用戶體驗。
   爲了解決這個問題，前端的模塊管理器（package management）應運而生。它能夠輕鬆管理各類JavaScript腳本的依賴關係，自動加載各個模塊，使得網頁結構清晰合理。不誇張地說，未來全部的前端JavaScript項目，應該都會採用這種方式開發。
基礎知識：
   ·主流模塊化標準分爲AMD（異步模塊定義）和CMD （通用模塊定義）。
   ·RequireJS 和 SeaJS 都是很不錯的模塊加載器，RequireJS遵循的是AMD規範，SeaJS遵循的是CMD規範。
   ·NPM的全稱是Node Package Manager，是一個NodeJS包管理和分發工具，已經成爲了非官方的發佈Node模塊（包）的標準。Nodejs自身提供了基本的模塊，可是開發實際應用過程當中僅僅依靠這些基本模塊則還須要較多的工做。幸運的是，Nodejs庫和框架爲咱們提供了幫助，讓咱們減小工做量。可是成百上千的庫或者框架管理起來又很麻煩，有了NPM，能夠很快的找到特定服務要使用的包，進行下載、安裝以及管理已經安裝的包。
   ·Webpack：是一個前端工具，可讓各個模塊進行加載，預處理，再進行打包，它能有Grunt或Gulp全部基本功能，並有許多其餘優勢。
   ·Babel:是一個普遍使用的轉碼器，能夠將ES6代碼轉爲ES5代碼，從而在現有環境執行。這意味着，你能夠如今就用ES6編寫程序，而不用擔憂現有環境是否支持。

1.JS的模塊化
   在ES6以前，JavaScript一直沒有模塊系統，這對開發大型複雜的前端工程形成了巨大的障礙。對此社區制定了一些模塊加載方案，如CommonJS、AMD和CMD等，某些框架也會有本身模塊系統，好比Angular1.x。
如今ES6已經在語言層面上規定了模塊系統，徹底能夠取代現有的CommonJS和AMD規範，並且使用起來至關簡潔，而且有靜態加載的特性。
規範肯定了，而後就是模塊的打包和加載問題：
①用Webpack+Babel將全部模塊打包成一個文件同步加載；
②用SystemJS+Babel分模塊異步加載；
③將二者結合在一塊兒。

2.CSS的模塊化
   雖然SASS、LESS、Stylus等預處理器實現了CSS的文件拆分，但沒有解決CSS模塊化的一個重要問題：選擇器的全局污染問題。
按道理，一個模塊化的文件應該要隱藏內部做用域，只暴露少許接口給使用者。而按照目前預處理器的方式，導入一個CSS模塊後，已存在的樣式有被覆蓋的風險。雖然重寫樣式是CSS的一個優點，但這並不利於多人協做。
爲了不全局選擇器的衝突，各廠都制定了本身的CSS命名風格：
·BEM風格；
·Bootstrap風格；
·Semantic UI風格；
·NEC風格；
   畢竟是弱約束。選擇器隨着項目的增加變得越多越複雜，而後項目組裏再來個新人帶入本身的風格，就更加混亂了。
   因此我很贊同這句話：與其費盡心思地告訴別人要遵照某種規則，以規避某種痛苦，倒不如從工具層面就消滅這種痛苦。
   從工具層面，社區又創造出Shadow DOM、CSS in JS和CSS Modules三種解決方案。
   ·Shadow DOM是WebComponents的標準。它能解決全局污染問題，但目前不少瀏覽器不兼容，對咱們來講還好久遠；
   ·CSS in JS是完全拋棄CSS，使用JS或JSON來寫樣式。這種方法很激進，不能利用現有的CSS技術，並且處理僞類等問題比較困難；
   ·CSS Modules仍然使用CSS，只是讓JS來管理依賴。它可以最大化地結合CSS生態和JS模塊化能力，目前來看是最好的解決方案。Vue的scoped style也屬於這一種。

 

二.組件化

   分治的確是很是重要的工程優化手段。在我看來，前端做爲一種GUI軟件，光有JS/CSS的模塊化還不夠，對於UI組件的分治也有着一樣迫切的需求：

   如上圖，這是我所信仰的前端組件化開發理念，簡單解讀一下：

1. 頁面上的每一個 獨立的 可視/可交互區域視爲一個組件；
2. 每一個組件對應一個工程目錄，組件所需的各類資源都在這個目錄下就近維護；
3. 因爲組件具備獨立性，所以組件與組件之間能夠 自由組合；
4. 頁面只不過是組件的容器，負責組合組件造成功能完整的界面；
5. 當不須要某個組件，或者想要替換組件時，能夠整個目錄刪除/替換。

   其中第二項描述的就近維護原則，是我以爲最具工程價值的地方，它爲前端開發提供了很好的分治策略，每一個開發者都將清楚的知道，本身所開發維護的功能單元，其代碼必然存在於對應的組件目錄中，在那個目錄下能找到有關這個功能單元的全部內部邏輯，樣式也好，JS也好，頁面結構也好，都在那裏。

   組件化開發具備較高的通用性，不管是前端渲染的單頁面應用，仍是後端模板渲染的多頁面應用，組件化開發的概念都能適用。組件HTML部分根據業務選型的不一樣，能夠是靜態的HTML文件，能夠是前端模板，也能夠是後端模板：

不一樣的技術選型決定了不一樣的組件封裝和調用策略。

   基於這樣的工程理念，咱們很容易將系統以獨立的組件爲單元進行分工劃分：

   因爲系統功能被分治到獨立的模塊或組件中，粒度比較精細，組織形式鬆散，開發者之間不會產生開發時序的依賴，大幅提高並行的開發效率，理論上容許隨時加入新成員認領組件開發或維護工做，也更容易支持多個團隊共同維護一個大型站點的開發。

   結合前面提到的模塊化開發，整個前端項目能夠劃分爲這麼幾種開發概念：

名稱	說明	舉例
JS模塊	獨立的算法和數據單元	瀏覽器環境檢測(detect)，網絡請求(ajax)，應用配置(config)，DOM操做(dom)，工具函數(utils)，以及組件裏的JS單元
CSS模塊	獨立的功能性樣式單元	柵格系統(grid)，字體圖標(icon-fonts)，動畫樣式(animate)，以及組件裏的CSS單元
UI組件	獨立的可視/可交互功能單元	頁頭(header)，頁尾(footer)，導航欄(nav)，搜索框(search)
頁面	前端這種GUI軟件的界面狀態，是UI組件的容器	首頁(index)，列表頁(list)，用戶管理(user)
應用	整個項目或整個站點被稱之爲應用，由多個頁面組成

   以上5種開發概念以相對較少的規則組成了前端開發的基本工程結構，基於這些理念，我眼中的前端開發就成了這個樣子：

示意圖	描述
	整個Web應用由頁面組成
	頁面由組件組成
	一個組件一個目錄，資源就近維護
	組件可組合， 組件的JS可依賴其餘JS模塊， CSS可依賴其餘CSS單元

   綜合上面的描述，對於通常中小規模的項目，大體能夠規劃出這樣的源碼目錄結構：

   若是項目規模較大，涉及多個團隊協做，還能夠將具備相關業務功能的頁面組織在一塊兒，造成一個子系統，進一步將整個站點拆分出多個子系統來分配給不一樣團隊維護。

3、規範化
   模塊化和組件化肯定了開發模型，而這些東西的實現就須要規範去落實。規範化實際上是工程化中很重要的一個部分，項目初期規範制定的好壞會直接影響到後期的開發質量。
   我能想到的有如下一些內容：
　　·目錄結構的制定
　　·編碼規範
　　·先後端接口規範
　　·文檔規範
　　·組件管理
　　·Git分支管理
　　·Commit描述規範
　　·按期CodeReview
　　·視覺圖標規範
   其中編碼規範最好採起ESLint和StyleLint等強制措施，由於人是靠不住的，好比能夠Lint通不過不能提交代碼等。

四.自動化

   做了這麼多年程序猿的我，一直秉持的一個理念是：任何簡單機械的重複勞動都應該讓機器去完成。因此我也認爲，前端工程化的不少髒活累活都應該交給自動化工具來完成。
①圖標合併
　　·不要再用PS拼雪碧圖了，有Gulp+SpriteSmith；
　　·不要再用Icomoon了，這仍然是半自動的，有FontCustom。
②持續集成
③自動化構建
④自動化部署
⑤自動化測試
   前端自動化測試可以提升代碼質量、減小人肉測試等，這些優勢是不言而喻的。市面上前端測試框架有不少，選擇哪一個都不會有太大問題，咱們用的是：Karma + Mocha + Chai
⑥構建工具
   最後就是你的團隊可能不僅一個項目，若是每一個項目都搭一套gulp+webpack+babel+...，維護成本比較高，並且不能保證統一性。
   所以基於Gulp實現一套獨立於項目的構建工具是最好的解決方案。能夠參考一下咱們網易蜂巢的構建工具rainfore/pursuit-cli，開發者只要會用pursuit dev和pursuit online兩句命令就行。

 

參考資料：https://github.com/fouber/blog/issues/10

參考資料：https://www.zhihu.com/question/24558375