前端自動化開發工做流

1. 前端自動化工做流簡介

每種項目都有本身特定的開發流程、工做流程。從需求分析、設計、編碼、測試、發佈，一個整個開發流程中，會根據不一樣的狀況造成本身獨特的步驟和流程。一個工做流的過程不是一開始就固定的，而是隨着項目的深刻而不斷地改進，期間甚至會造成一些工具。例如當年大神們在Linux寫C語言，以爲每次編譯好多文件好麻煩，就發明了makefile。不一樣代碼的管理好麻煩，而後就發明了git、SVN等等。

一個工做流程的好壞會影響你開發的效率、開發的流程程度，而後間接影響心情，打擊編碼積極性。因此我認爲開發一個項目的時候，編碼前把工做流程梳理清楚肯定下來是一個很是重要的步驟。而且這個流程要在真實環境中不停的改進。

對於要負責頁面結構和內容、外觀、邏輯的前端來講，一個好的工做流相當重要。並且這裏中沒有銀彈。要根據具體項目所使用的框架、應用場景來進行調整獨特的工做流。

我會介紹一個我常用的前端工做流，這個工做流只是一個原始的流程，通常來講，我會根據不一樣項目的不一樣來在這個基礎上進行調整，造成每一個項目獨特的流程。因此這裏的重點是領會構建工做流的思路，而後學會觸類旁通。

一個前端自動化開發流程中，我以爲至少須要作到如下幾點：

1. 良好的模塊化
2. 自動化編譯
3. 自動化測試
4. 實時刷新頁面
5. 自動化打包、壓縮發佈

能用機器的地方就不要本身動手，除了上述必備的幾點，有時候要根據特定的狀況編寫一些Python、Nodejs、Shell腳原本避免重複的操做。好好呵護你的F5和稀疏的腦神經，男人要對本身好一點。

2. 儲備知識

在正式介紹以前會先作一些儲備知識的介紹，也會略過一些你可能不懂的知識。懂的話能夠跳過，遇到不懂的能夠本身Google，不要百度。

2.1 工程目錄

個人工程目錄通常是這個樣的：

├─assets/
│  └─images/
├─bin/
├─dist/
├─lib/
├─src/
│  ├─coffee/
│  │  └─main.coffee
│  └─less/
│     └─main.less
├─test/
│   └─specs/
├─node_modules/
├─index.html ├─Gruntfile.coffee ├─package.json ├─.gitignore └─README.md 

全部子目錄名稱不少都其實源於古老的C語言工程。

assets：通常存放的是圖片、音頻、視頻、字體等代碼無關的靜態資源，我通常只有圖片，有時候也會新建一個fonts文件夾什麼的。

bin：binary的縮寫，這個名字來歷於咱們古老的C語言工程，由於通常C語言要編譯成可執行的二進制文件什麼的，後來基本成爲了一種默認的標註。因此前端編譯好的文件也會存放在bin/目錄下。

dist：distribution的縮寫，編譯好的bin中的文件並不會直接用於發佈，而是會通過一系列的優化操做，例如打包壓縮等。最終可以部署到發佈環境的文件都會存放在dist裏面，因此dist裏面是可以直接用到生產環境的代碼。

lib：library的縮寫，存放的是第三方庫文件。例如你喜歡的jquery、fastclick什麼的。可是接下來你會看到，在咱們的模塊化方式中，這個文件夾通常是比較雞肋的存在。

src：source的縮寫，全部須要開發的源代碼的存放地，咱們通常操做地最多的就是這個文件夾。簡單地分爲coffee、less兩個文件夾，存的是邏輯代碼和樣式（我通常用CoffeeScript和LessCss，固然你也能夠改爲你喜歡的語言，JS，TS，LS，SASS，思路是同樣的）。你看到兩個文件夾下分別有main.coffe、main.less，這實際上是邏輯代碼和樣式代碼的主要入口文件，會把其餘模塊和樣式引進來，經過某種機制合成一個文件。接下來會詳細解釋。

另外，這個目錄的組織方式會根據實際狀況多變。有時候你會須要html模板，可能會多一個tpl/目錄。也許你的目錄不是這種基於文件類型的層次組織，而是基於頁面部件的組織，就可能出現components/目錄，而後下面有不少個頁面部件的目錄，每一個子目錄有本身的coffee、less、html。（這種形式也變得逐漸流行。由於基於文件類型目錄，當工程複雜起來的時候，就會變得異常難以維護，基於部件就會至關方便）。

test：使用測試驅動（TDD）開發進行編程，這裏存放的都是測試樣例。

index.html：頁面文件

接下來幾個文件都不解釋，不瞭解的能夠先預習NodeJS、Git、Grunt這幾個東西。

2.2 模塊化

提及前端模塊化又是一個能夠長篇大論話題。前端模塊化的方式有不少種，年輕人最喜歡用的就是RequireJS、SeaJS什麼的，看到這些模塊化工具的時候感受就像本身的第一雙滑板鞋那樣那麼興奮。其實這種AMD、CMD都須要引進一個庫文件來作模塊化工具，並且配置複雜，各類異步加載問題多多。後來我發現其實最clean、直接、方便、強大模塊化方式當屬substack大神的真.Browserify。

它能夠基於NodeJS平臺實現模塊化的工具，你能夠像組織NodeJS代碼那樣組織本身的前端工程，全部的模塊均可以像NodeJS那樣直接require進來。提供一個入口文件（如上的main.coffee)給Browserify，它會把這個入口文件的全部依賴模塊都打包成一個文件。最終的文件不依賴於Browserify，最終的文件就是你的邏輯代碼的組合。

並且Browserify和NodeJS的模塊兼容性很好，一些NodeJS自帶的模塊例如util、path均可以用到前端中。你用npm安裝的庫，也能夠經過Browserify用到前端中！例如我想用jQuery，我只須要：npm install jquery --save。而後在main.coffee中：

$ = require "jquery" // play with jquery 

至關貼心。

（Browserify具體用法查看官網文檔）

2.3 流程自動化工具

其實自動化方式能夠有不少種，你能夠：

• 配置npm的script，直接用npm來進行自動化任務管理。
• 使用古老的makefile和shell腳本
• Grunt
• Gulp

前兩種方式更適合NodeJS開發服務端的應用場景，前端通常更適合用後兩種。

目前使用的是Grunt，選擇它是由於它社區大、插件多、成熟。可是我更看好Gulp基於流(Stream)的機理，這種繼承於Unix思想的無與倫比的實現方式着實可讓它在性能上和Grunt拉開差距。Grunt基於文件實現方式是在是：太！慢！了!

（Grunt具體用法能夠見官網文檔）

2.4 測試

測試又是一個龐大的話題。在國外，前端TDD、BDD開發已經至關成熟，各類酷炫的工具Jasmine、Mocha、Tape等等，多是我比較孤陋寡聞，貌似國內不多見到這些工具的使用。

其實前端是很難作到徹底測試驅動開發的，它自己涉及到許多主觀判斷因素，例如動畫是否是按照預想的那樣移動等等。可是邏輯代碼和先後端接口邏輯是能夠測試的。因此引進測試驅動開發的一個很是大的好處就是：只要接口肯定了，先後端能夠分離開發，前端不用再「等後端API實現」了。

在咱們的工做流中，使用MochaJS做爲測試套件，ChaiJS做爲斷言庫，Sinon作爲數據mocking和函數spy。具體用法能夠看各自的官網。

（對前端測試驅動開發不瞭解的同窗能夠Google相關資料或查閱相關書籍）

3. 自動化工做流

3.1 模板

這個工做流的模版已經存放到了github上，你們能夠clone下來進行本地測試一下：https://github.com/livoras/feb.git

運行步驟：

1. 電腦上必須先按安裝好Nodejs和npm

2. 安裝browswerify，coffeescript，和grunt：

   npm install browswerify coffee-script grunt-cli -g

3. 把倉庫fork到本地，進入工程目錄，安裝依賴：

   npm install

4. 而後運行grunt命令

運氣好的話你能夠看到這樣的界面:

而後，你會發現工程目錄下多了一個bin文件夾，那就是咱們剛編譯好的文件存放在bin中。

而後打開瀏覽器，進入http://localhost:3000 ，能夠看到：

如今咱們修改src/less/main.less文件，把body改爲黑色看看：

而後回到瀏覽器看看：

說變就變，很是哦妹子（amazing）是否是？

工做流分兩個簡單的步驟：

1. 開發時
2. 分佈時

如今來介紹一下。

3.2 開發時

咱們來看看gruntfile的100～108行：

其實grunt幹了這麼幾件事：

1. 開啓本地服務器進行調試：使用grunt的一個connect插件，開啓了一個本地服務器，localhost:3000，工程目錄爲根目錄。
2. 刪除原來已經以前已通過時的編譯文件：刪除整個bin文件夾
3. 編譯coffeescript而且使用browserify進行依賴合併：將src/coffee/下面的main.coffee做爲入口，把全部依賴模塊編譯成js而且合併成一個文件，存放到bin/js/目錄下。打開bin/js/你能夠看到下面有一個main.js。細心但話，你會發現，其實main.coffee是依賴同目錄下的一個叫another-module.coffee的模塊的。在編譯的時候，browserify會分析整個main.coffee的依賴樹，而後找到全部依賴進行合併，因此你看到的bin/js/main.js實際上是包含了兩個模塊的內容。因此咱們能夠用Nodejs的方式寫模塊，前端只須要合併好的文件就能夠了。
4. 編譯less：將src/less/main.less編譯到bin/css/目錄下，一樣的， Less也是能夠相似coffee的方式引用模塊（經過import）。因此咱們的樣式也是萌萌噠模塊化了。
5. 運行測試：全部的測試存放在test/specs下，編譯好之後，grunt會運行moch運行測試樣例。你在窗口中能夠看到咱們一共有三個測試運行而且經過了。
6. 監控文件變化，一旦文件變化，從新執行3～5步驟。而且自動刷新瀏覽器：藉助於grunt的watch插件，咱們能夠作到一旦文件修改的時候，就從新編譯coffeescript，less，運行測試，而且自動刷新瀏覽器。

有了這麼一個流程，你就能夠很輕鬆地寫前端的邏輯和樣式，而且都是以模塊化的方式。

3.3 發佈時

好了，代碼都寫完了。我須要把個人代碼部署到服務器上。很簡單，只須要命令行中執行：

grunt build 

你就會發現工程目錄下多了一個dist文件夾，進入裏面，能夠看到：

直接打開index.html：

竟然能夠直接打開，也是很是哦妹子是否是？

咱們看看grunt的build任務：

grunt build幹了這麼幾件事情：

1. 刪除以前編譯過的文件，同上。
2. 刪除以前發佈的文件，也就是刪除整個dist目錄。
3. 編譯coffee和less，同上。
4. 測試，發佈前仍是須要看看有沒有問題嘛。
5. uglify，把bin/js/main.js混淆壓縮，放到dist/js/下。
6. cssmin，把bin/css/main.css混淆壓縮，放到dist/css下。
7. 複製assets目錄到dist下
8. 複製index.html，作一些處理（更改相對路徑等），存放到dist/下

你能夠看到dist目錄下的文件js和css文件都是通過壓縮的，如今dist中的文件夾已經ready了，你隨時均可以直接放到服務器上了。

4. 最後

上面實際上是一個很是簡陋的流程，在實際要作的流程化要比這個複雜多，例如要考慮組建目錄自動化構建，版本管理自動化，部署自動化，圖片合併優化等等。主要有這個意識：* 不要作任何重複的工做，能自動化到地方均可以想法設法作到自動化 *。

上面也跳過了不少基礎知識，這些是你須要知道的：

1. Grunt的使用
2. Nodejs的基本使用
3. 模塊化概念
4. TDD測試的概念和基本測試套件的使用
5. Coffee，Less，Browserify但使用等

我甚至直接跳過了構建整個流程的過程，也跳過了測試如何編寫。其實其中不少細節均可以拓展來說，測試，模塊化等，接下來博客也許會往這個方向去寫。