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

時間 2019-11-30

標籤前端工程系列閒談腳手架简体版

原文原文鏈接

Version：2019.09.08.v1.2

開篇

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

當初訂的每週至少一篇原創文章的規矩儘可能不破，因此就算不能玩剛出的《怪物獵人：冰原》也要把文章給你們補上。。。

書接上回，上回書說到「前端工程化之腳手架」，談了一談胖子認爲的前端腳手架的定義和服務內容。此次我們再閒談一下下面幾個問題。

腳手架的還應具有的特質（對以前文章中的一些觀點的補充）
常見的腳手架介紹
腳手架實現的思路
製做腳手架可能依賴的相關庫

腳手架還應該具有的特質

封裝性（隔離性）

引用《前端工程化：體系設計與實踐》（好書推薦）書裏的一段話，

「前端工程體系的功能涵蓋範圍廣，封裝的方案類型多，對應的配置項也很是複雜。並且，大多數前端工程體系的開發者並非一線的業務開發者。對於業務開發者來講，這套工程體系就是一個黑盒，他們不須要了解其中的複雜原理，只須要知道如何配置便可。因此業務開發者的需求就是快速開發快速配置，而且生成的配置項跟項目要對應，既要知足項目的功能需求，又不能有「混淆視聽」的冗餘功能。」

封裝和隔離，目的就是對非必要的工程化體系的技術細節封裝到一個黑盒中，對一線業務開發人員從沒必要要的工程體系相關繁瑣的工做開發任務隔離開來，提升相關業務人員關注的業務自己，提升專一性，提升生產效率。

兼容性

因爲腳手架使用的特殊性，大部分使用場景是在工程師的本地平臺上，因此，一個優秀的腳手架，就須要考慮到多個系統平臺的支持，理論上講不能有平臺限制（除非這個腳手架是僅僅是服務大家內部項目而且大家公司的開發環境是高度統一的）

靈活性（可擴展性）

針對這個特性，胖子想先強調是針對內部項目或內部業務而產生的客制腳手架，首先是咱們的腳手架應該儘可能具有靈活性和寬展性，那麼怎麼理解這點呢？

由於如今前端的多樣性和複雜性，服務於咱們本身業務項目的腳手架應該考慮以後業務變化帶來的技術更替，要考慮技術兼容的問題，因此一個靈活的可配置的腳手架設計就會爲從此的升級更新帶來便利。在腳手架的設計之初就要考慮到這點，那麼爲了不過分設計，胖子建議參考下面幾點建議。

考慮好你的腳手架的服務生命週期的目標，設計好每一個生命週期階段的任務，以後再向不一樣的生命週期的籃子裏填充你的功能，儘可能保持週期之間互不影響。
如引用第三方的模塊，儘可能引用第三方模塊的原有功能接口，若有成熟的配置工具模塊，儘可能調用成熟的模塊功能，這樣在以後的技術更新中，若是第三方模塊接口不變，咱們就不須要作額外的工做作兼容。
前期儘可能功能不要太多，只提供必要的功能支持，由於功能少就意味着依賴更少，靈活性可控。

業務和工程目標驅動性

補充這點，主要是強調一下腳手架最終的目的是爲業務和工程服務的，應該是業務和工程驅動腳手架變化的，而不該該是工程師團隊，它不是技術的練兵場和百寶箱，不是任何一個工程師以爲一個新技術或新點子不錯，就把這些加入到咱們的腳手架裏面。腳手架的目的都是純粹的，「服務業務，提升效率」。

目前任何一個和前端相關的庫和框架，ReactJS，VueJS，Express等等的腳手架的目的都是統一和純粹的，讓用戶快速上手熟悉它們的東西，下降框架自身的學習成本。推廣它們的產品和業務。因此，一個好的腳手架，應該是爲業務和工程服務的。

常見的腳手架介紹

下面列出三個業界稍有名氣庫或框架的腳手架（其實大部分主要仍是提供工程初始化功能的），都是知名框架和庫提供的generator腳手架，相信用過相關框架和庫的你應該都很熟悉的。

Yeoman

最後一個是yeoman，它的主頁上對本身的定義是「用Web腳手架工具構建Web APP，優化你的工做流，讓你快速，優雅的Coding！」。其實胖子對其的理解就是一個web app的generator的構建系統，你能夠在Yeoman生命週期基礎上構建本身的腳手架generator，也能夠在它現有的generators（3900+）裏查找到你的腳手架快速生成你的web項目。

yeoman.io/

yowebapp.github.io/

腳手架實現思路

其實，腳手架的實現思路，特別是項目初始化腳手架的實現思路，胖子以爲套路仍是很簡單的。就和要把大象關冰箱裏是同樣的，總（nong三聲啊）共就那麼幾步。。。這裏咱們借鑑一下Yeoman的生命週期來看看實現本身的腳手架咱們須要思考的思路。

初始化：這一步主要是啓動腳手架，校驗項目的狀態，獲取一些基本的配置信息等。
獲取用戶配置：這一步就是經過互動交互的方式獲取用戶的定製化配置信息。
解析配置信息：處理上一步的用戶定製化配置信息，結合項目自身的相關默認配置，生成解析出最終的項目配置。
生成項目模板文件：針對最終生成的項目配置，生成項目的基本模板文件結構。這一步通常有兩種經常使用方式生成模板文件，一種是在已有的代碼倉庫中獲取，例如從git上下載下來；另外一種是根據配置動態解析生成模板文件。也有的項目是兩種的結合，例如項目的初始文件（例如angualr的component相關文件）直接下載，項目相關的配置文件（例如tsconfig）則動態解析生成。
收尾：這一步簡單了，工做作完了，必定要作好清理和還原工做啊。

項目初始化搞定了，剩下的就要思考在前端工程化過程當中各個階段你的腳手架計劃提供的功能feature了，好比本地開發服務器等。這個就是具體需求出具體的解決方案了。