【雲途君有話說】每一個成功男人的背後都有一個（也許幾個）默默支持（啰嗦雞婆）的女人；每一款極致體驗的產品背後，都有一個（或者一群）孜孜專業（悶騷瘋狂）的技術男。繼之前「雲途壹看板」演算法工程師撰寫了《推薦系統---使用logistic的原因和不足》之後，又一位前端工程師步入了「IT偽宅男」的行列，以一篇結合專業、深入淺出的文章告訴我們：技術宅男的小情懷一旦帥炸，必同老房子著火一樣不可救藥！

如果把雲途壹看板比作正在蓬勃發育的活力生命體，那麼它必將經歷曾經、現在、以及未來的成長軌跡，也總會經歷從粗糙到成熟的蛻變過程。

本文以前端開發中樣式文件載入的一點問題，和大家聊一聊雲途壹看板在自動化過程中的那些事。

（圖片來自網路）

先解釋下名詞，啥叫自動化構建？維基百科裡是這樣說的：

自動化構建（英語：Build automation），又稱構建自動化、組建自動化，將軟體設計師的每日工作，以自動化技術或腳本語言方式，自動完成的工具與技術。其中主要包括了：以編譯器將源代碼編譯成二進位碼（Binary code）、將二進位碼打包成軟體包、運行單元測試、部署軟體（Software deployment）、產生文件與Release notes。

簡單來說，就是讓計算機自己工作，並輸出最終滿足業務需求的東東！我們今天要聊的就是其中關於軟體部署相關的一小塊內容。

聖經里裡面有位耶穌大爺曾經說過，「 你們或以為樹好，果子也好。樹壞，果子也壞。因為看果子，就可以知道樹」 【太12:33】。

（圖片來自網路）

啥意思呢？ 就是看結果說話。拿雲途壹看板產品介紹頁面為例：

小時候它長這樣：

經過構建，現在長成這樣：

哪裡長得不一樣呢？圖片有點袖珍，且容我細細道來。

為了方便進行比較，本例中僅羅列了CSS文件請求列表，兩個版本之間僅有樣式部分有所差異，並且瀏覽器都是第一次從硬碟直接讀取CSS樣式文件（避免緩存帶來的差異）。

首先是文件請求數的差異

從圖中可以看到，前後兩者之間在文件請求數上，相差了整整6個CSS文件請求。

前端攻城獅們都知道，網站請求數過多將會對網站的性能產生影響。雖然這一點並不是絕對的，但對於CSS文件的載入這一點還是比較重要的。（比如對於JS的優化方案，由於雲途壹看板屬於應用型網站，所以更多的是考慮應用的可用性，從而犧牲了請求帶來的性能消耗）

其次是頁面總載入時間的變化（載入大小的差異）

構建前與構建後，在總文件大小上分別是 187.7KB和164KB，而最終的頁面載入時間差異更大，分別是 12.69s和2.42s。

為什麼僅通過對樣式文件的一個簡單優化，兩者之間就會產生這樣大的差異呢？

首先自動化構建工具中引入了CSS壓縮功能，把所有樣式文件整理至一個文件當中（不考慮新的樣式文件中引入的新代碼，否則壓縮率將更高），其次是多個文件請求轉化成單個請求帶來的性能提高也是一個重要點。不要小看這一點點的優化，對於大型網站來說可以節省的帶寬可不是一點點能夠描述的。

一點看不到的差異

在傳統的前端開發中，如果對樣式文件（JS文件）經過壓縮後，對於我們調試和修改代碼將帶來一定的困難。

針對這一點，雲途壹看板在構建代碼時我們加入SourceMap的支持，對於目前主流瀏覽器（如Chrome)，通過SourceMap可以快速定位我們開發代碼的具體位置。這樣，我們可以通過使用「重命名」插件，方便地維護壓縮和未壓縮的兩套代碼，並且快速部署到項目的相關目錄中。

也許，大家會說：「納尼？這麼簡單的事，地球人全知道！！！「

（圖片來自網路）

誠然，這點「小料」對於大部分的攻城獅來說並不新鮮，But，這並不影響我們通過這個例子，了解到自動化構建能夠做的一些事情：

• LESS編繹

• 文件合併/壓縮

• SourceMap的應用

除此之外，僅針對前端開發，自動化構建工具還可以做很多事情。比如：

• 版本控制

• JS檢查、壓縮及編繹ES6代碼

• 文件重命名

• 圖片URL轉化

• 單元測試等等

那麼，為什麼要引入自動化構建流程（工具）？

回答這個問題， 那就要聊聊以前前端的開發方式，姑且叫它「老式開發方式」。

在老式開發方式中，我們一般直接使用CSS語法對樣式進行管理。隨著各種插件和開發庫的引入，樣式文件也會隨之增多，各插件樣式代碼之間的載入順序有可能會間接影響最終的瀏覽器輸出結果。為此，常規的做法是把第三方的樣式文件放在項目樣式文件之前，並且在項目文件中針對第三方的樣式進行重新定義等等。

這樣的開發方式，在對站點進行整體的規劃時將非常麻煩。例如項目中為了應用公司的UI規範，統一全站的字體時，不得不在很多的位置編寫相同的代碼。隨著項目的推進，它的維護成本將越來越高。

針對這種問題，可以嘗試通過引入SASS或者LESS工具，像寫腳本語言一樣對樣式進行變數、函數的定義，以及合理規劃多個樣式文件之間的結構以方便導入。屆時，就不可避免的引入相應的編譯工具，而為了簡化重複的勞動，使用自動化構建工具配置它們將是不錯的選擇。

同樣，針對JS文件、圖片文件、代碼版本管理等也會有相應的工具和自動化的方式，自動化構建流程的引入將大大減少我們的勞動量和提升開發的效率。

然後，自動化構建工具都有哪些？該怎麼選擇？

當前，市面上有許多類型的自動化構建工具。其中比較知名的有：Gulp、Grunt、NPM + Webpack。

這三款產品都是基於Node.js的，都有不同的優缺點。我們今天不談論各款工具之間的區別，僅羅列一些需要考慮的點，來輔助大家的選擇合適的工具。

在開發雲途壹看板這個項目（產品）時，我們主要考慮這樣幾個問題：

• 構建工具的成熟程度以及社區的支持程度（是否有足夠的文章拿來啃）；

• 腳本是否容易維護，方便地編寫相應的業務邏輯（是否容易理解和學習）；

• 是否有豐富的插件來滿足想要達到的目的（少寫點代碼，以使用為主，研究為輔）

通過以上的幾點考慮，雲途壹看板最終選擇了gulp作為構建工具，解決了JS的模塊化構建、CSS樣式文件的管理以及資源文件的管理和項目部署，隨著項目的推進也在不斷優化構建流程。

除此以外，可能還需要考慮一些其它的問題。比如針對重要依賴插件的更新情況；構建性能的要求等等。

每一個團隊、開發的項目都不太一樣，針對具體情況選擇最優的方案將是最好的選擇。

最後，自動化構建是萬能的嗎？

（圖片來自網路）

也許，真正的逼格永遠是用最合理選擇，產生了最佳的效果…… 就像世間永遠沒有絕對一樣，萬能這樣的事情誰敢隨便說？它已經不屬於地球的範疇。

自動化構建流程的目的是為了把重複工作一次性配置，多次重複執行，從而帶來的開發效率的提升，也將避免一些人為誤操作帶來的風險。這樣就可以讓開發人員從瑣細的工作中解放出來，專註於項目功能、業務邏輯的實現。若「為了逼格而逼格」，未免有些得不償失。

當然，雲途壹看板的開發同樣也經歷了從屌絲到高逼格的轉變，正是因為這樣對細節的不斷追求，所以相信它的每一點小小的打磨和進步，都將帶給大家越來越好的體驗。

更多大數據技術乾貨，請點擊「雲途壹看板」

推薦閱讀：