F++：別忽略前端工程化的部署與測試

時間 2019-11-06

標籤忽略前端工程部署測試简体版

原文原文鏈接

寫在前面

不知不覺時間已來到2017年的4月，不知道2016年的前端技術概念爆炸，是嚇走了技術小白，仍是讓技術大牛多加幾天班呢。However，Web前端這個領域並未熱度退減，從學校畢業走進這個行業的人不可勝數，後端終於不鄙視切圖仔，固然切圖仔也再也不只是個切圖仔，甚至有從非互聯網轉過來學前端的。javascript

在面試前端工程師的時候，相信各位面試官都或多或少的會說起一個前端領域很是熱的話題——前端工程化。我面試的時候都會問應聘者：「說說你對前端工程化的理解？」你們第一反應都是想到自動化構建相關的內容，grunt、gulp、webpack等等，編譯ES6啊，編譯Sass啊，分割代碼啊，合成雪碧圖啊……而後就是前端以往刀耕火種，如今有了更多的規範和流程等等。php

面試老是有點緊張我能理解，但面試了幾十我的，尚未人說起前端工程化中很重要的兩個方面：部署和測試。css

在這裏我很是感激我是軟件工程專業畢業的，我很天然就會發現前端開發流程中有哪些地方還很「原始」。確實，如今前端構建工具普遍應用於執行一些自動化的構建任務，但實際上，它們能作更多，nodejs的發展也支持咱們能作更多，例如自動化部署和自動化測試。html

所以，我想說的是：別忽略前端工程化的部署和測試。前端

什麼是軟件工程

維基百科 - 軟件工程
研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把通過時間考驗而證實正確的管理技術和當前可以獲得的最好的技術方法結合起來的學科。vue

實際上軟件工程和其餘的工程有不少相似的地方，只是由於目前你們都還聚焦於核心技術和功能的實現上，因此纔會相對地忽略工程的其餘部分。絕不誇張的說，作一個Web App，流程上應該和建一座橋樑是基本一致的：從前期的設計、邏輯的驗證、需求的制定，到實現方案的落地執行、執行過程當中的修正（debug）、部件的構建，到最後的總體測試、驗收等等。好吧，面對現實，大多數的軟件都是在缺乏充分的需求、過程當中系統的迭代管理以及後期的測試的環境下誕生的。java

「上線是第一任務，有bug的話在後面的版本更新中解決吧！」node

「因此說土木工程的PR和軟件工程的PR，是不能互換的，呵呵。」webpack

我只是想對這個浮躁的IT界發表個人一點小意見：軟件也是工程，就由於橋樑塌了會危及生命，而軟件崩了大不了debug重啓，你們就不重視軟件的工程化問題了嗎？git

什麼是前端工程化

「什麼是前端工程化」，「爲何要有前端工程化」，「前端工程化的好處」。這些問題已經有大把的好文章可供閱讀。在這裏簡單講述一下前端工程化的內容。

前端工程能夠說是軟件工程的一個細分領域，流程類似，但特色鮮明。先來講說前端，固然我指的是Web前端，相比其餘方向的技術有什麼特色：

提及前端，至少涉及3種語言。（html，css，javascript）
前端代碼在用戶端運行時增量安裝。（摘自張雲龍的文章，資源和代碼都是增量下載的）
最基本的情況下，前端代碼不須要編譯（即改即生效）。
瀏覽器即運行環境，很是易於調試和開發（不須要simulator）。

基於上面的情況，最原始的項目只須要一個index.html，只要你的電腦有一個正常的瀏覽器，就能開工了。上面說的是原始的狀況，如今，咱們的前端項目NB起來了，引入了大量的新技術。咱們須要編譯了，ES6咱們用Babel；咱們開始寫單元測試了，須要跑測試的腳本了；咱們前端團隊人員增多了，須要更好的協做和維護；咱們的資源須要處理成多個不一樣的版本去適應不一樣的終端，咱們的資源須要被打成不一樣的包……這時候，就能夠開始討論前端工程化的內容了。

前端工程化須要解決如下問題：

規範性，文本編輯器很方便，但語法提示，風格檢查會迫使你去將本身的IDE打造起來的。
資源管理，前端最頭疼的事情，所幸咱們有Webpack！
自動化任務，debug、build、deploy、test、documentation等。
模塊化開發，劃分好模塊老是便於團隊協做，使軟件邏輯清晰。
組件化開發，也許你想說這是框架負責的，實際上前端工程化的支持纔是最重要的。

到這裏，你可能會發現，你最近在搗鼓的一些事情，有很多是在解決前端工程化的問題的。

你給你的編輯器例如SublimeText配置了linter，裝了一堆輔助開發的插件，語法補全、路徑提示，甚至取色器等等，因而你的編輯器更像一個IDE了；你的團隊都使用Airbnb的標準，代碼風格總算是獲得了統一了；你開始使用grunt、gulp、webpack等等來完成一些自動化構建的任務，壓縮、編譯、混淆代碼的工做都交給它們好了；爲了首屏大家也許會選擇使用code spliting達到按需加載……

廢話太多了，下面有一大波技術文章供你們學習。總而言之，前端工程化不是簡單的指自動化構建，要是你面試的時候這麼回答我會很失望的。

其餘公司的前端工程化總結：
前端工程化：雲構建 - 淘寶前端團隊FED
咱們是如何作好前端工程化和靜態資源管理 - 京東凹凸實驗室
 前端工程化開發方案app-proto - 美團點評技術團隊

部署和測試也很重要

先說說部署

介紹完前端工程化後，你們想必對前端工程化有一個相對完整的概念了，而在文章的開頭我說了，但願你們不要忽略部署和測試的環節。會使用構建工具完成一些自動化任務不等於實現了前端工程化，你還須要考慮代碼部署和測試的部分。下面連接中張雲龍的回答讓我受益很大，是這個回答啓發我迫使本身要更加劇視前端工程化的：

大公司裏怎樣開發和部署前端代碼？ - 張雲龍/知乎

結合我自身經從來說說，咱們處理前端資源的更新部署的問題的演變過程（只是個示例）：

版本1.0 資源放服務器上

<script src="/js/main.js"></script>

版本2.0 資源放CDN上

放服務上太慢了，所有資源都得轉到CDN上！當時以爲刷新CDN真的麻煩啊，因而自做聰明，加個版本號的GET參數不就行了？每次update的時候更新版本號就行了~

<script src="//xxx.cdn.com/js/main.js?v=<?php echo $version; ?>"></script>

版本3.0 使用gulp、webpack等加文件摘要

對比2.0更精確控制緩存了，回頭一看之前有沒有像傻同樣，更新一個小版本所有資源都刷新緩存了。

<script src="//xxx.cdn.com/js/main.js?v=f33103ed68b9b31df7b5"></script>

版本4.0 看似一小步，實際一大步

我就不解釋這和3.0的最重要的區別在哪兒了，一個是覆蓋式發佈而另外一個是非覆蓋式發佈。你們能夠看看上面我推薦的張雲龍的回答，更好的理解這個問題。

<script src="//xxx.cdn.com/js/main.f33103ed68b9b31df7b5.js"></script>

列舉上面這個例子，我想說明的是這些事情就是該前端來想的呀，而前端工程化中部署這一環節是不容忽視的。這個環節中包含的內容不僅是上面的緩存控制，例如更新前確保資源自動部署到OSS、CDN等。代碼部署除了效率之外更重要的是準確性和穩定性，而在前端工程化中重視部署環節能夠加強部署的準確性和穩定性。寫好你的部署腳本吧，一鍵更新，用戶只多花了0.2秒下載新資源就能體驗新版本，將讓你感受很是酷。

再來講說測試

「測試？打開瀏覽器點一下按鈕看看有沒有報錯不就行了?」

就算不說起迴歸測試會讓你崩潰的問題，上面的這種方法也太原始了，前端代碼的質量也是所以而久久提不到一個比較高的水平。其餘的領域早就提出了各類測試方法，設有專門的崗位來測試項目，列出了一大堆的測試用例，甚至使用大牛向的TDD（Test-Driven Development）。作那麼多事情，還不是爲了提升代碼質量，提升軟件的穩定性！

因而前端也開始作單元測試，e2e測試方面的工做了。建議使用vue-cli的webpack template來試着建立一下項目，能夠選擇使用Karma+Mocha作單元測試，使用Nightwatch作e2e測試。