前端工程化系列之閒談「腳手架」（上）

Version：2019.08.28.v1.1

開篇

你們好，我是王小胖，一個集可愛與智慧於一身的胖子。

說到前端工程化，首先想到的是這個小小的概念，「腳手架」。

What？Why？什麼是前端腳手架？

相信你們只要接觸過前端開發，確定接觸過腳手架（Scaffold）這個概念，或者或多或少使用過它。因爲前端腳手架「閱後即焚，用後即棄」的特性，雖然能給前端開發初始階段帶來不小的便利，可是還彷彿如流星閃過通常，不被前端工程化領域所重視，但這裏胖子想說，「前端腳手架，它真的，真的，很不錯！」

胖子在網上和書籍中查找了一段時間，也沒有找到一個對前端腳手架有一個滿意的定義。因此今天我們就直接開始我們的閒談，在閒談的過程當中尋找完善腳手架的定義吧。Let's GO！

快速

相信你們但凡接觸過知名的和前端有關的，或其餘的框架和庫的，不管是Angular， VueJS， ReactJS， 或者是Express，NPM等等，都應該使用過這些框架或庫提供的腳手架，Angular CLI，Vue CLI， create-react-app， express generator等等。

這些腳手架的最主要目的就是可以讓你避開繁瑣的項目初始化配置工做，讓你快速上手這些框架和庫所提供的功能，使你儘快愛上它們。。。想象一下，沒有它們提供的腳手架，對於新手來講，你有可能須要花費大半天的時間才能將你的Demo項目跑起來，至少你須要徒手碼代碼好長時間吧。。。暫且不說能不能堅持到項目啓動成功，就是這麼長時間，你對於這個庫或者框架也已經失去耐心了吧。

因此從咱們第一印象來看，胖子給前端腳手架的定義就是

「快速構建項目的初始化文件結構的工具。」

可配置

咱接着來，在你們使用的腳手架工具中，你都會經歷在你的初始「init「命令以後，都會緊跟着幾個配置的相關問題須要你回答，「項目名字是什麼啊？git地址啊？使用的style文件格式？使用的模版技術？有沒有女友啊？？？！！！」。你會發現腳手架提供給咱們不少配置選項供咱們靈活的生成初始文件。

因此胖子將腳手架的定義補充了一點。

「快速且可配置的構建項目的初始化文件結構的工具。」

避免重複

OK，繼續。你們假想一下沒有腳手架的狀況，你或你的項目組接到了一個新的前端項目，須要重新構建整個工程，大家技術選型爲VueJS 2.X，typescript，SCSS加 PWA等。可能你或團隊技術過硬，不到半天，很快利用webpack基礎和構建工具整理出了項目開發和構建的文件基本結構，能夠開始工做了。可是過幾天大家又有一個項目須要一樣的技術選型來構建項目，以後呢，大家老闆發現大家的項目結構不錯，打算推廣到整個公司。難道整個公司的項目組都須要重複以前的工做，從新構建，本身寫代碼？不該該，也是不可能的，過低效了，不能被我們可愛的程序員接受啊。

這時候大家會想，不如咱們構建一套項目文件模版供全部項目組下載吧，這樣你們就不會再作重複的工做了，不過很快你發現固定的項目模版的不足了，有的項目組style打算用less。。。那再出一套針對less的文件模版。。。固然不行了，太Low了，不能被我們可愛的程序員接受啊。這時候你就會想到利用可配置的腳手架爲全部項目組提供初始的項目文件結構了，避免了開發人員大量的重複繁瑣的工做。

因此我們再對腳手架的定義作一個補充。

「快速且可配置的，避免重複工做的，構建項目的初始化文件結構的工具。」

規範化

前端技術的百花齊放，百鳥爭鳴。技術的自由多樣性一樣帶來了技術棧的難統一的問題，公司跨項目跨部門間，技術如何規範化是一個很大的挑戰。怎麼能避免行政死命令來讓這些桀驁不馴的可愛的程序員們統一技術棧，實現技術的規範化呢？

胖子以爲咱們能夠從工程化的角度下手，充分利用腳手架來「弱強制化」地推行技術的規範化和統一化。

胖子這裏說的不是限制可愛的程序員們只能選用固定的某一門技術，強制不能選擇其餘技術。而是在必定的過濾後的範圍內靈活技術選型。

胖子認爲「無規矩無以成方圓」，小的創業公司勉強還好，人員少，靈活性帶來的高效和利益實際上短平快地優於規範性帶來的穩定和安全的利益。可是對於成規模的公司，具有大量開發人員的公司，公司的一線開發部門，在技術選型和技術使用上就須要犧牲一些靈活性，工程師應該定位在適當範圍內的容許適當的靈活性，這樣能夠爲公司開發部門帶來很多的益處。

• 下降學習和溝通成本。不一樣的開發部門，不一樣的開發人員，能夠在必定範圍內的技術上溝通，交流（未規範前多是20個技術，規範後可能只有5個技術），討論具體的細節的問題了，不用再額外花時間來預學習一些以前沒有接觸或熟悉的技術了。
• 下降項目開發和維護成本，技術範圍的領域的縮小，帶來的，一是在各個項目中技術問題的排查解決方案就能夠重用，例如B組遇到的問題可能A組以前就有了解決方案了，或者A組直接在腳手架中下載的公共模塊上就把問題修復了，B組根本不會再發生一樣的問題。二是各個項目部門建立的通用業務模塊有可能通過加工後被各個部門重用，方便構建公司級別的統一的物料庫。
• 下降新技術選型風險，規範化到腳手架中可用的技術理論上都是通過基礎部門過濾過的，或是通過公司權威專家認證過的，因此能夠規避不少盲目選型新技術帶來的風險。固然這對基礎部門也一樣提出了更高的選型和審覈要求，怎麼把控這個粒度？怎麼實現規範和靈活性的統一？怎麼快速響應需求？都是須要認真思考的問題。

這樣，咱們再擴展一下咱們對腳手架的定義

「快速且可配置化的，避免重複工做，統一技術規範化的構建項目初始化文件結構的工具。」

When？Where？腳手架的生命週期？

其實你們若是查詢或瞭解對於腳手架的介紹和講解的文章，或者看咱們在以前造成的定義，都會看到一個詞 「初始」。這也給了腳手架定下了一個「刻板印象」，「閱後即焚，用後即棄」。其實胖子以爲這對腳手架的見解是落後的，狹隘的。

胖子認爲腳手架不該該只是服務於建立項目的初始文件，理論上它應該能夠在整個項目週期上提供支持和服務。雖然不少工做的支持都是在初始構建的階段完成或定義的，可是咱們應該放開咱們的思想禁錮，擴展腳手架對整個工程化的貢獻。

你們能夠回想一下現實的中建築的腳手架不也是一直對整個建築週期起到保駕護航的做用嘛，爲何前端的腳手架不能呢？

另外，如今市場上活躍的，人氣高的腳手架產品，咱們已經能看到有的已經將功能擴展到整個項目生命週期的不少步了，不僅是侷限於初始構建這一步。腳手架徹底能夠慢慢成爲前端整個領域的整合型工具。

下面列舉胖子瞭解的腳手架在整個項目週期內能夠提供哪些支持和服務：

1.構建階段

不用多說了，前面尋求定義的過程已經說的很清楚了。。。（實際上是胖子真的寫不動了。。。還不想Ctrl+C，Ctrl+V。。。）

2.開發階段

本地代碼熱更新支持，提升開發效率。

本地mock service服務，實現先後端並行開發，下降項目交付風險。

自動生成新模塊代碼，省去繁瑣工做。

代碼提交的預檢查，提升代碼的穩定性。

3.測試階段

mock測試數據。

執行測試腳本。

生成統一的測試報告/並上傳統一服務器作質量監控。

4.部署階段

部署前預檢查。在項目部署以前，自動執行一些必要檢查來保證穩定性和安全性。

自動部署，一般大廠或正式成規模的大公司，部署理論上會有獨立的部門來維護，或者會有一套成熟的pipeline來供開發人員使用。可是對於小公司和非正式產品的demo項目，咱們徹底能夠將部署的工做放到腳手架上自動化處理。

5.運維階段

奇怪!? 腳手架還能服務於運維!？其實你們若是像胖子同樣放下對腳手架的刻板印象，而是把它定義成服務於前端整個項目週期的「工具」，腳手架爲何不能爲運維階段作點事呢？好比數據統計和產品穩定性和性能監控。

結語

其實在上面的5個階段裏，胖子還想加入一個階段，就是「無限制階段」，意思就是咱們不要侷限於上面的五個階段，任什麼時候候，任何地點咱們遇到的問題，若是能經過增強腳手架來合理解決，咱們均可以考慮進去。

其實，若是咱們真正的把腳手架當成一個爲前端整個項目週期，或整個項目領域服務的工具，還有不少事和功能實現能夠放到腳手架裏面。

你可能會有疑問，那照胖子你這麼說，那豈不是腳手架就由一個簡單編輯的單一職能的便捷工具，變成了一個面面俱到，無微不至的複雜繁瑣的大怪物了嗎！？這樣真的好嗎！？

這裏胖子想說明一點，咱們做爲可愛的程序員，任何一個工具或工具裏功能的產生，咱們都是須要思考一個問題的。這麼作到底是不是能解決咱們實際的問題？能提升咱們的效率？能節省咱們的成本？這些纔是最重要的。咱們不該該爲了全而全，爲了完美而完美。咱們可愛的程序員生下來就是爲了解決實際問題的。因此爲何腳手架單單隻能是一個工具呢？不能是工具集，工具庫呢？現實中建築的腳手架也是不少堅固的零部件組合而成的啊，因此咱們不要被固定的思惟侷限和阻擋住咱們的創新和思考。

最後，胖子給出本身對前端腳手架的定義。

「前端腳手架，狹義上講，是快速且可配置化的，避免重複工做，統一技術規範化的構建項目初始化文件結構的工具。廣義上講，也是服務於整個前端項目週期，提供完善技術支持，解決方案的工具集合。」

PS：胖子會在以後的文章中應該會接着說說腳手架相關的東西。敬請期待！

1. 胖子認爲的好的腳手架的特色和功能
2. 業內好的腳手架項目簡單介紹
3. 簡單介紹如何寫一個狹義上服務於初始構建階段的腳手架

若是您有什麼問題和建議，歡迎留言。

若是您以爲胖子的文章還過得去，麻煩你輕點右上角的轉發朋友圈按鈕。胖子這裏拜謝了。

轉載請註明 碼農王小胖