我最開始的想法是搭一套工程環境，本也是很正常不過的事情，但是隨着用的多了，就會發現幾個問題：
1、架構與業務耦合：剛寫完的時候的確是結構分明，都是架構代碼，還沒寫業務，但是隨着慢慢的交給不同的人穿插維護，好多架構代碼就會被加入好多的業務邏輯，一旦想動一動架構，就會發想藕合在一起的代碼已經很難再拆分開了。
2、不好移植：我第一次寫完后，下一個項目又要從老項目中去把非業務的東西復用出來，但是過了好久我自己都很難分清哪些是非業務的架構代碼，何況是新的項目不一定是我來寫，既沒有時間每個人搭一套工程（沒時間，也不利於架構統一），不能每個人復用的時候在把我叫過去。
3、不能快速上手：剛剛提到的問題就提到在快節奏的工程迭代中，我們必須面臨交叉維護、新人入職、老員工離職等一系列問題，快速的上手顯得相對重要。既然想快速上手，就要有一套統一的項目配置，並且這個配置只暴露出少量的命令。維護這個配置要與業務分離。
第一步：首先它要是一個“腳手架”
基於上面的需求，我的第一步是先寫一套配置，然后把它做成腳手架。我首先想到的是參考vue－cli的思路：能夠初始化出我想要的工程目錄，里面有我的工程配置。vue－cli的做法是通過初始化命令拷貝出一份基本的工程，然后通過npm script中命令完成開發、打包的操作來實現一個單頁面應用。我們第一步就可以模仿這個思路。
上一篇文章中介紹過，我的前端工具通過發布到npm平台后再全局安裝，終端運行命令 $ coodev XXX 是可以讀取到這個XXX的，換句話說就是我打算開發我的工具中的第一個命令（功能）： $ coodev init 。考慮到以后要有不止一個命令，我打算寫一個map。簡單來說就是每一個職務模塊暴露一個render方法，這個map做一個命令字符和render()的映射。
我不浪費時間直接介紹第一個功能：init
一個腳手架是什么，就是把一套寫好的項目配置的項目模板從一個維護的地方拷貝到項目文件夾下，這樣就可以維護腳手架解藕，每一次init都應該拿到最新迭代的項目模板。換句話說就是，你要信有一套配置（我建議在單開一個git倉庫維護這個項目模板）。我的模板放在https://github.com/grARM/coodev-temp-normal
任務已經簡化到寫一個工程配置了，只要提煉以前的項目積累，考驗的就是前端工程化的基本功了，但是我接下來簡單介紹一下我幾個注意事項：
1、不要過於細致，不帶業務，可分化多模板：
之前每次搭建一個項目的時候可能會為了開發的便利，耦合了不少與項目相關的業務邏輯，而我們這一次要做的是通用模板，就不能帶有業務邏輯。因此我們要找到細致與通用中間的一個“度”。骨架應該僅僅包含開發、編譯、打包等邏輯。當然也不能為了通用就寫的很少，每一個通用模板是為了處理一類業務的，比如PC前台、WAP前台、后台admin、專題頁等。我不打算一個模板“同吃”所有類別的項目，相反我們划定類別后，一個模板如果不能兼容，就用多個模板來對應，但要保證提供統一的接口工我們的開發工具“調遣其他任務”。
2、統一接口
剛剛提到多模板的管理問題，雖然有不同的模板，但是一些基本命令比如編譯、打包上線都應該交給我的工具統一管理。比如我有一條命令 $ coodev dev 這條命令是監聽源碼目錄下的文件修改，即時編譯。那么我們每一個模板的都應該達到這個功能，要么都采用類似的工程目錄結構，要么各自准備一個文件供dev調用。我才用了后者，原因是這樣可以讓哥哥模板配置更靈活。
3、獨立文件導出，對應多平台，無縫對接
我們雖然是一個前端工具，但要考慮server端的配合，畢竟你要在server渲染。如果server是nodeJS，就相當於同一種引擎渲染。但是往往大多數公司采用JAVA或PHP的server。渲染引擎一般是JSP、smarty等不同的引擎。為了和原有項目無縫對接。我們的編譯結果應該是導出對應的*.jsp、*.php或*.vm等文件。對應js、css應該合並壓縮。最好是在模板中預留一個配置文件，目的是對應適配server端的目錄結構。
4、模板的獨立維護
模板是我的前端工具的一部分，雖說很重要，但不影響工具的主體邏輯。我比較建議將模板的維護放在另一個git倉庫，再開發好模板后同步到工具中，或工具自己去github上拉取。
第二步：“不僅僅”是一個腳手架
剛剛說到作為第一步的腳手架，來完成項目的初始化。作為腳手架來說，任務已經完成了。我們的工具要在整個項目中對項目進行控制，單純的初始化、拷貝模板是不夠的。之前用過一些腳手架，一些就沒有其他命令了，另一寫好一點的大多吧命令定義在npm scripts 中，這樣往往控制的是當前目錄下的文件。這樣腳手架工具的生存周期就結束了，工具就對項目沒有了控制權。如果將一些命令的控制權交給我們的工具。這樣我們還可以更多的整合一些資源，比如一條命令可以對兩個倉庫下操作，也可以編譯、打包、同步上線倉庫等一鍵執行。
除了之前的初始化，我們還可以做些什么呢？
1、編譯、打包、輸出
2、本地服務
3、mock調試
4、本地渲染
第三步：有了雛形，我們來體驗一下
目前我的coodev提供了幾條基礎命令，全局安裝coodev后 $ sodu cnpm install coodev -g 在我們的開發目錄下運行 $ coodev init 初始化目錄后在安裝依賴 $ cnpm install 后期考慮直接將安裝依賴整合到 init 命令中，真正做到coodev統一控制。
接着運行 $ coodev dev 啟動開發模式即時編譯，和 $ coodev start 啟動本地服務，用於開發調試。也可以復合命令 $ coodev dev start 同時啟動兩個任務。
更多的命令可以在安裝后通過命令 $ coodev -help 來查看。
總結：
一個工具的基本雛形已經設計完成，總結一下我們工具的初步規划的相當於“腳手架 plus”。我們的思路很明確：在完成腳手架的前提下，加入更多的實用功能，讓我們的工具可以完成整個前端開發的各個階段。我們做的一切，實為了在前端開發的每一個階段可以不依賴於server的開發環境，可以很快的展開工作，不用等待接口的提供。而最終又可以無縫對接
最終實現切圖期間的分工協作、共用組件復用、架構上的前后分離。下一篇文章會針對一個模板介紹這些目標是如何實現的。