一、腳手架
腳手架這個詞在編程領域初次看到是在使用前端框架時。許多團隊在制定前端工程方案時會加入腳手架模塊。雖然不同的團隊對工程化的理解和實施有所差異，但是對於腳手架的定位基本是一致的：創建項目初始文件。這是一條看起來十分簡單地准則，但是對於這條准則應該如何理解，如何實施卻並不是一件很簡單地事情。
在探索這條准則的深度之前，我們不妨看看類似的一些成熟方案，比如Eclipse。這個大名鼎鼎的IDE軟件被很多Java和Android開發者使用。通過Eclipse創建一個新項目時，它提供了豐富的配置項，這些配置項可以歸納簡化為以下流程：選擇項目類型 -> 選擇項目目錄 -> 配置項目細節 -> 最終確認 -> 完成。這是腳手架最基本也是必須具備的流程。從這個流程中可以總結出腳手架的本質：方案的封裝。
由此，我們明確了腳手架的定義：腳手架作用是創建項目的初始文件，本質是方案的封裝。
腳手架在前端工作流中負責項目起始階段創建初始文件。與其他功能模塊不同的是，腳手架是一個完全“啟下”的模塊，它沒有任何前置依賴。創建完成項目初始文件之后，腳手架就再無用武之地了。
“用完即棄”的工作模式令腳手架的實現由很大的躍遷性。你可以用最簡單的復制粘貼就能完成腳手架的工作，而一個完備、成熟的腳手架即使提供了非常豐富的交互配置，最終目的也“只”是創建了一堆初始的項目文件。既然結果一樣，那為什么還要花費時間和人力成品去開發復雜的腳手架方案呢？
這是一個非常現實的問題，互聯網產品迭代的快速節奏下，開發團隊最注重的就是投入產出比，而腳手架的投入產出比“看上去”是最低的。環顧目前前端的工具生態，最多的是構建工具，當然我們不可否定構建確實是最復雜的功能。而腳手架工具是最少的，前端社區對腳手架的討論也非常稀少。你可能聽說過大名鼎鼎的yeoman，但是很難再想出第二個腳手架工具了。
單獨來看，腳手架可能並不具備很高的“性價比”，但如果你的團隊有一套完整的前端工程體系，腳手架的作用就會被放大。前端工程體系的功能涵蓋范圍廣，封裝的方案類型多，對應的配置項也非常復雜。而且，大多數前端工程體系的開發者並不是一線的業務開發者。對於業務開發者來說，這套工程體系就是一個黑盒，他們不需要了解其中的復雜原理，只需要知道如何配置即可。所以業務開發者的需求就是快速開發快速配置，並且生成的配置項跟項目要對應，既要滿足項目的功能需求，又不能有“混淆視聽”的冗余功能。
前端工程體系不是Vue、React這種開發框架，工程體系只是一種“服務”，是輔助性質的。學習曲線應該平緩，即使文檔再清晰易懂，也不應該要求業務開發者去花時間學習各種細節。這就是腳手架要解決的切實問題，簡單說就是：
- 快速生成配置；
- 降低框架學習成本。
隨着前端工程體系越來越復雜，腳手架的角色會越來越重要。
二、腳手架之於編程
1，寫代碼之前
在寫項目代碼之前，你可能得先這么做一些事：
選擇包管理工具，初始化 package.json 文件
查找項目引用的框架依賴和工具依賴包，並逐一安裝相關的包
針對已安裝的包分別寫對應的配置
配置本地 web server，代理靜態資源文件
2，可能還需要做其它事
做完上面的事情之后，你才能開始去寫一個“hello world”。這只是配置了一個開發環境，如果引入測試環境，你還得安裝單元測試的相關的依賴包，寫對應的配置和運行腳本，發布到生產環境則需要進行代碼合並、壓縮、混淆，規范化的發布可能還要引入持續集成工具。
3，面臨的問題
由此可見，這些復雜的配置對於一個不經常寫前端代碼，准確說是對於不經常寫這些配置的開發者來說是非常不友好的。不過，大部分前端領域在發展過程中面臨的問題，往往在其他編程領域早已出現過，並且已經有比較成熟的解決方案，上面所描述的配置繁瑣的問題，我們可以引入腳手架工具來解決。
4，腳手架重新定義
腳手架本質上就是一套工具，由於在web2.0時代，應用變復雜后，出現了很多可以讓前端開發效率提升的框架和標准及工具等等，可能這些新的代碼方式遠行環境還不支持，也許我們需要一個本地測試環境和運行環境及調試環境等，所以需要一套完整的工具幫我們處理問題及項目構建。
一般不同的技術棧也會有自己的目錄結構，工作流程，如vue，angular等都會有自己的腳手架，通常叫xxx-cli。曾經我比較常用的yeoman可以根據不同的生成器成為不同項目的腳手架工具，非常不錯。自己手動搭建一個適合自己實際項目情況的腳手架工具也是可以的。