我想寫一個前端開發工具（二）:不單單是個腳手架

　　我最開始的想法是搭一套工程環境，本也是很正常不過的事情，可是隨着用的多了，就會發現幾個問題：

　　一、架構與業務耦合：剛寫完的時候的確是結構分明，都是架構代碼，還沒寫業務，可是隨着慢慢的交給不一樣的人穿插維護，好多架構代碼就會被加入好多的業務邏輯，一旦想動一動架構，就會發想藕合在一塊兒的代碼已經很難再拆分開了。

　　二、很差移植：我第一次寫完後，下一個項目又要從老項目中去把非業務的東西複用出來，可是過了很久我本身都很難分清哪些是非業務的架構代碼，況且是新的項目不必定是我來寫，既沒有時間每一個人搭一套工程（沒時間，也不利於架構統一），不能每一個人複用的時候在把我叫過去。

　　三、不能快速上手：剛剛提到的問題就提到在快節奏的工程迭代中，咱們必須面臨交叉維護、新人入職、老員工離職等一系列問題，快速的上手顯得相對重要。既然想快速上手，就要有一套統一的項目配置，而且這個配置只暴露出少許的命令。維護這個配置要與業務分離。

第一步：首先它要是一個「腳手架」

　　基於上面的需求，個人第一步是先寫一套配置，而後把它作成腳手架。我首先想到的是參考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

　　任務已經簡化到寫一個工程配置了，只要提煉之前的項目積累，考驗的就是前端工程化的基本功了，可是我接下來簡單介紹一下我幾個注意事項：

　　一、不要過於細緻，不帶業務，可分化多模板：

　　　　以前每次搭建一個項目的時候可能會爲了開發的便利，耦合了很多與項目相關的業務邏輯，而咱們這一次要作的是通用模板，就不能帶有業務邏輯。所以咱們要找到細緻與通用中間的一個「度」。骨架應該僅僅包含開發、編譯、打包等邏輯。固然也不能爲了通用就寫的不多，每個通用模板是爲了處理一類業務的，好比PC前臺、WAP前臺、後臺admin、專題頁等。我不打算一個模板「同吃」全部類別的項目，相反咱們劃定類別後，一個模板若是不能兼容，就用多個模板來對應，但要保證提供統一的接口工咱們的開發工具「調遣其餘任務」。

　　二、統一接口

　　　　剛剛提到多模板的管理問題，雖然有不一樣的模板，可是一些基本命令好比編譯、打包上線都應該交給個人工具統一管理。好比我有一條命令 $ coodev dev 這條命令是監聽源碼目錄下的文件修改，即時編譯。那麼咱們每個模板的都應該達到這個功能，要麼都採用相似的工程目錄結構，要麼各自準備一個文件供dev調用。我才用了後者，緣由是這樣可讓哥哥模板配置更靈活。

　　三、獨立文件導出，對應多平臺，無縫對接

　　　　咱們雖然是一個前端工具，但要考慮server端的配合，畢竟你要在server渲染。若是server是nodeJS，就至關於同一種引擎渲染。可是每每大多數公司採用JAVA或PHP的server。渲染引擎通常是JSP、smarty等不一樣的引擎。爲了和原有項目無縫對接。咱們的編譯結果應該是導出對應的*.jsp、*.php或*.vm等文件。對應js、css應該合併壓縮。最好是在模板中預留一個配置文件，目的是對應適配server端的目錄結構。

　　四、模板的獨立維護

　　　　模板是個人前端工具的一部分，雖然說很重要，但不影響工具的主體邏輯。我比較建議將模板的維護放在另外一個git倉庫，再開發好模板後同步到工具中，或工具本身去github上拉取。

　　

第二步：「不只僅」是一個腳手架

　　剛剛說到做爲第一步的腳手架，來完成項目的初始化。做爲腳手架來講，任務已經完成了。咱們的工具要在整個項目中對項目進行控制，單純的初始化、拷貝模板是不夠的。以前用過一些腳手架，一些就沒有其餘命令了，另外一寫好一點的大多吧命令定義在npm scripts 中，這樣每每控制的是當前目錄下的文件。這樣腳手架工具的生存週期就結束了，工具就對項目沒有了控制權。若是將一些命令的控制權交給咱們的工具。這樣咱們還能夠更多的整合一些資源，好比一條命令能夠對兩個倉庫下操做，也能夠編譯、打包、同步上線倉庫等一鍵執行。

　　除了以前的初始化，咱們還能夠作些什麼呢？

　　一、編譯、打包、輸出

　　二、本地服務

　　三、mock調試

　　四、本地渲染

第三步：有了雛形，咱們來體驗一下

　　目前個人coodev提供了幾條基礎命令，全局安裝coodev後 $ sodu cnpm install coodev -g 在咱們的開發目錄下運行 $ coodev init 初始化目錄後在安裝依賴 $ cnpm install 後期考慮直接將安裝依賴整合到 init 命令中，真正作到coodev統一控制。

　　接着運行 $ coodev dev 啓動開發模式即時編譯，和 $ coodev start 啓動本地服務，用於開發調試。也能夠複合命令 $ coodev dev start 同時啓動兩個任務。

　　更多的命令能夠在安裝後經過命令 $ coodev -help 來查看。

總結： 

　　一個工具的基本雛形已經設計完成，總結一下咱們工具的初步規劃的至關於「腳手架 plus」。咱們的思路很明確：在完成腳手架的前提下，加入更多的實用功能，讓咱們的工具能夠完成整個前端開發的各個階段。咱們作的一切，實爲了在前端開發的每個階段能夠不依賴於server的開發環境，能夠很快的展開工做，不用等待接口的提供。而最終又能夠無縫對接

　　最終實現切圖期間的分工協做、共用組件複用、架構上的先後分離。下一篇文章會針對一個模板介紹這些目標是如何實現的。