轉載--web前端工程化

       

做者：趙雨森
連接：https://www.zhihu.com/question/24558375/answer/139920107
來源：知乎

## 模塊化

簡單來講，模塊化就是 將一個大文件拆分紅相互依賴的小文件，再進行統一的拼裝和加載。只有這樣，纔有多人協做的可能。

### JS的模塊化

在ES6以前，JavaScript一直沒有模塊系統，這對開發大型複雜的前端工程形成了巨大的障礙。對此社區制定了一些模塊加載方案，如CommonJS、AMD和CMD等，某些框架也會有本身模塊系統，好比Angular1.x。

如今ES6已經在語言層面上規定了模塊系統，徹底能夠取代現有的CommonJS和AMD規範，並且使用起來至關簡潔，而且有靜態加載的特性。

規範肯定了，而後就是模塊的打包和加載問題：
1. 用 Webpack+ Babel將全部模塊打包成一個文件同步加載；
2. 用 SystemJS+ Babel分模塊異步加載；
3. 將二者結合在一塊兒。

### 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也屬於這一種。

## 組件化

首先，組件化≠模塊化。好多人對這兩個概念有些混淆。

模塊化只是在語言層面上，對代碼的拆分；而組件化是基於模塊化，在設計層面上，對UI（用戶界面）的拆分。

從UI拆分下來的 每一個包含模板(HTML)+樣式(CSS)+邏輯(JS)功能完備的結構單元，咱們稱之爲組件。

其實，組件化更重要的是一種 分治思想。

Keep Simple. Everything can be a component.

這句話就是說頁面上全部的東西都是組件。頁面是個大型組件，能夠拆成若干個中型組件，而後中型組件還能夠再拆，拆成若干個小型組件，小型組件也能夠再拆，直到拆成DOM元素爲止。DOM元素能夠當作是瀏覽器自身的組件，做爲組件的基本單元。

傳統前端框架/類庫的思想是先組織DOM，而後把某些可複用的邏輯封裝成組件來操做DOM，是DOM優先；而組件化框架/類庫的思想是先來構思組件，而後用DOM這種基本單元結合相應邏輯來實現組件，是組件優先。這是二者本質的區別。

其次，組件化其實是一種按照模板(HTML)+樣式(CSS)+邏輯(JS)三位一體的形式 對面向對象的進一步抽象。

因此咱們除了封裝組件自己，還要合理處理組件之間的關係，好比 （邏輯） 繼承、 （樣式） 擴展、 （模板） 嵌套和 包含等，這些關係均可以歸爲 依賴。

其實組件化不是什麼新鮮的東西，之前的客戶端框架，像WinForm、WPF、Android等，它們從誕生的那天起就是組件化的。而前端領域發展曲折，是從展現頁面爲主的WebPage模式走過來的，近兩年才從客戶端框架經驗中引入了組件化思想。其實咱們不少前端工程化的問題均可以從客戶端那裏尋求解決方案。

目前市面上的組件化框架不少，主要的有 Vue、 React、 Angular 2、咱們公司

@ 鄭海波

的Regular、Avalon等。你感興趣能夠都研究一下，選擇一套中意的。其實Vue文檔中的對比其餘框架一文已經講得很詳細了。

## 規範化

模塊化和組件化肯定了開發模型，而這些東西的實現就須要規範去落實。
規範化實際上是工程化中很重要的一個部分，項目初期規範制定的好壞會直接影響到後期的開發質量。

我能想到的有如下一些內容：

• 目錄結構的制定
• 編碼規範
• 先後端接口規範
• 文檔規範
• 組件管理
• Git分支管理
• Commit描述規範
• 按期CodeReview
• 視覺圖標規範
• ...

其中編碼規範最好採起ESLint和StyleLint等強制措施，由於人是靠不住的，好比能夠Lint通不過不能提交代碼等。
先後端接口管理能夠了解一下咱們公司出的NEI - 接口管理平臺。

## 自動化

做了這麼多年程序猿的我，一直秉持的一個理念是：

任何簡單機械的重複勞動都應該讓機器去完成。

因此我也認爲，前端工程化的不少髒活累活都應該交給自動化工具來完成。

### 圖標合併

• 不要再用PS拼雪碧圖了，有Gulp+SpriteSmith；
• 不要再用Icomoon了，這仍然是半自動的，有FontCustom。

### 持續集成
### 自動化構建
### 自動化部署
### 自動化測試

前端自動化測試可以提升代碼質量、減小人肉測試等，這些優勢是不言而喻的。
市面上前端測試框架有不少，選擇哪一個都不會有太大問題，咱們用的是：
Karma + Mocha + Chai

### 構建工具

最後就是你的團隊可能不僅一個項目，若是每一個項目都搭一套gulp+webpack+babel+...，維護成本比較高，並且不能保證統一性。

所以基於Gulp實現一套獨立於項目的構建工具是最好的解決方案。

能夠參考一下網易蜂巢的構建工具rainfore/pursuit-cli，開發者只要會用pursuit dev和pursuit online兩句命令就行。