一、許多團隊在制定前端工程方案時會加入腳手架模塊。雖然不同的團隊對工程化的理解和實施有所差異，但是對于腳手架的定位基本是一致的：創建項目初始文件。這是一條看起來十分簡單地準則，但是對于這條準則應該如何理解，如何實施卻并不是一件很簡單地事情。
二、在探索這條準則的深度之前，我們不妨看看類似的一些成熟方案，比如Eclipse。這個大名鼎鼎的IDE軟件被很多Java和Android開發者使用。通過Eclipse創建一個新項目時，它提供了豐富的配置項，這些配置項可以歸納簡化為以下流程：選擇項目類型 -> 選擇項目目錄 -> 配置項目細節 -> 最終確認 -> 完成。這是腳手架最基本也是必須具備的流程。從這個流程中可以總結出腳手架的本質：方案的封裝。
三、腳手架作用是創建項目的初始文件，本質是方案的封裝。
1.腳手架在前端工程中的角色
1.1 “用完即棄”的腳手架
595796-20170330204649539-235709455.jpg
腳手架在前端工作流中負責項目起始階段創建初始文件。與其他功能模塊不同的是，腳手架是一個完全“啟下”的模塊，它沒有任何前置依賴。創建完成項目初始文件之后，腳手架就再無用武之地了。
“用完即棄”的工作模式令腳手架的實現由很大的躍遷性。你可以用最簡單的復制粘貼就能完成腳手架的工作，而一個完備、成熟的腳手架即使提供了非常豐富的交互配置，最終目的也“只”是創建了一堆初始的項目文件。既然結果一樣，那為什么還要花費時間和人力成品去開發復雜的腳手架方案呢？
這是一個非常現實的問題，互聯網產品迭代的快速節奏下，開發團隊最注重的就是投入產出比，而腳手架的投入產出比“看上去”是最低的。環顧目前前端的工具生態，最多的是構建工具，當然我們不可否定構建確實是最復雜的功能。而腳手架工具是最少的，前端社區對腳手架的討論也非常稀少。你可能聽說過大名鼎鼎的yeoman，但是很難再想出第二個腳手架工具了。
單獨來看，腳手架可能并不具備很高的“性價比”，但如果你的團隊有一套完整的前端工程體系，腳手架的作用就會被放大。前端工程體系的功能涵蓋范圍廣，封裝的方案類型多，對應的配置項也非常復雜。而且，大多數前端工程體系的開發者并不是一線的業務開發者。對于業務開發者來說，這套工程體系就是一個黑盒，他們不需要了解其中的復雜原理，只需要知道如何配置即可。所以業務開發者的需求就是快速開發快速配置，并且生成的配置項跟項目要對應，既要滿足項目的功能需求，又不能有“混淆視聽”的冗余功能。
前端工程體系不是Vue、React這種開發框架，工程體系只是一種“服務”，是輔助性質的。學習曲線應該平緩，即使文檔再清晰易懂，也不應該要求業務開發者去花時間學習各種細節。這就是腳手架要解決的切實問題，簡單說就是：
- 快速生成配置；
- 降低框架學習成本。
隨著前端工程體系越來越復雜，腳手架的角色會越來越重要。
######1.2 腳手架需要具備的要素
1.2.1 執行環境僅限本地
在討論實現一個腳手架要考慮哪些要素之前，我們不妨先看看腳手架的執行環境。回顧前文提到的簡易前端工作流，最簡單的情形是：框架提供一套完整的本地工具鏈，腳手架、開發、開發服務器、構建和部署測試都是在本地環境執行，如下圖：
進一步的團隊會搭建CI（持續集成）平臺，將構建和部署功能遷移至云端，這樣做便于工作流程控制和代碼統一管理。如下圖：
不論哪種工作流，腳手架始終是在本地執行。
1.2.2 模式不固定
前端腳手架之所以沒有固定的模式，是由于不同的公司對于前端工程師的定位不固定。比如有些公司的前端仍然是“切圖仔”；有些公司的前端負責瀏覽器端的所有邏輯開發但是html模板層仍然由服務端工程師維護；還有些比較前沿的團隊提倡“大前端”，負責瀏覽器層與中間層（主要承載html的渲染功能）。前端工程師定位的不固定造成了前端項目模式的不固定，腳手架自然也具備了多樣性。
不論是哪種工作模式，一個優秀的前端腳手架都應該具備以下幾點要素：
1.豐富但不繁瑣的配置項；
2.與其他功能模塊聯動，生成對應的基本配置項；
3.自動安裝依賴；
4.底層的高度可擴展性；
5.支持多種運行環境，比如命令行和Node.js API。
如何理解“豐富但不繁瑣”呢？舉個例子，假設構建功能支持自動生成css sprites，配置項有兩個：
1.是否啟用css sprites；
2.指定散列icon目錄。
腳手架在實現針對css sprites的配置項時是不是應該將這兩個配置都開放給用戶配置呢？顯然是不需要的，腳手架只要開放是否啟用css sprites的配置項即可，因為這是影響這項功能最重要的一點，散列icon的目錄即使用戶不配置，使用默認的方案也不會造成任何不便。
另外，在實現腳手架時不應該只看到當前的需求，還應該考慮后續需求的變更和新增。所以一個優秀的腳手架應該具備高度的可擴展性，便于定制不同類型的方案。從這個角度來說，目前yeoman是做得最好的。
####2. 開源前端腳手架方案剖析
>明確了腳手架的基本工作模式，我們不妨看看目前業內有哪些可以借鑒的案例。我們在這里介紹三種形態的腳手架：
- [sails](http://sailsjs.com/)是一個Node.js fullstack框架，其使用的[sails generate](http://sailsjs.com/documentation/reference/command-line-interface/sails-generate)腳手架主要是針對服務端代碼設計；
- 優酷PHP中間層框架是筆者前團隊使用的開發框架，目前并未開源。其使用的腳手架相對sails來說比較簡單，只能創建一個完整的webapp，包括Controller層和瀏覽器層代碼；
- [yeoman](http://yeoman.io/)是廣為人知的開源腳手架工具，它本身不提供任何直接創建文件的功能，而是一個腳手架底層框架，你可以定制自己的腳手架實現。
######2.1 sails - Node.js fullstack框架
sails是一個Node.js全棧框架，服務端使用MVC架構。[sails generate](http://sailsjs.com/documentation/reference/command-line-interface/sails-generate)是sails的腳手架模塊，默認可以創建以下幾種模塊的初始代碼：
- app - 創建一個新sails項目；
- api - 創建一對model和controller；
- model - 創建一個model；
- controller - 創建一個controller；
- adapter - 創建一個adapter；
- generator - 創建一個腳手架模板。
~~~sails框架中的[Adapter](http://sailsjs.com/documentation/concepts/extending-sails/adapters)可以簡單理解為簡化model操作API的映射適配器。
大家注意最后一種類型：generator。sails在默認的腳手架基礎上，開放了自定義腳手架模板的[API](http://sailsjs.com/documentation/concepts/extending-sails/generators/custom-generators)。
sails默認的腳手架大都是針對服務端代碼的，如果不借助其他腳手架模板，瀏覽器端的代碼（JavaScript/CSS/Views）只能手動添加。
######2.2 優酷 - PHP中間層框架
優酷的PHP中間層框架并未開源，所以就粗略的介紹一下吧。
中間層框架不涉及Model層，不涉及數據庫操作，只包括Controller和View層。這個框架的理念是：任何一個模塊都被視為一個webapp，每個webapp都是一個SPA，比如登錄/注冊模塊Passport、訂閱模塊Subscribe等。腳手架只能創建一種文件類型：一個完整的webapp。其中包括Controller文件、Resource文件（瀏覽器層）和路由配置文件。
由于每個模塊webapp都是一個SPA，包含一個Controller文件，一個view入口文件、一個入口js文件和一個css文件，所以腳手架創建的初始文件就已經夠用了，開發者只需要手動添加子模塊文件即可。同時，技術棧統一，build功能封裝完備，不需要額外配置。這種形態的腳手架基本滿足了優酷PHP中間層框架的需求
######2.3 yeoman - 可能是最好的開源腳手架框架
提起腳手架這三個字就不得不提yeoman這名老將。Yeoman在2012年Google I/O上首次發布，至今已經5年的光景了。對于前端技術圈子來說，5年的時間可以讓絕大部分的技術遭到淘汰，而yeoman堅持到了今天，且扔未現衰退之勢。我們可以短暫回顧一下5年前的前端技術，你可能會想到Knockout和Backbone，也可能會想到YUI 3，甚至可能會想起被ExtJS所支配的恐怖。然后再看看這些在當時熱火朝天的技術目前的市場狀態，是否都已是昨日黃花垂垂老矣？而yeoman之所以能“活”這么久，得益于它明確的定位。
yeoman的slogan是“THE WEB'S SCAFFOLDING TOOL FOR MODERN WEBAPPS”-腳手架工具，但我個人認為稱之為腳手架框架更為合適。yeoman不能直接創建項目文件，它提供了一套完整的開發腳手架API，你可以通過這些API定制符合自己業務需求的任意的腳手架方案。換句話說，yeoman不封裝任何方案，它是完全開放、高度可擴展的。
yeoman的API具備了前文所列出的腳手架需要具備的所有要素，如果你需要開發一個屬于自己的腳手架，yeoman是最好的選擇。后續的博文會詳細介紹如何使用yeoman提供的Node.js API將其集成到工程化框架中。
###3. 總結
雖然前端腳手架沒有固定形態，但是有必須具備的要素。從功能實現的角度，要考慮與業務的高度匹配；從底層框架的角度，要具備高度的可擴展性和執行環境多樣性支持。
