我最开始的想法是搭一套工程环境，本也是很正常不过的事情，但是随着用的多了，就会发现几个问题：
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的开发环境，可以很快的展开工作，不用等待接口的提供。而最终又可以无缝对接
最终实现切图期间的分工协作、共用组件复用、架构上的前后分离。下一篇文章会针对一个模板介绍这些目标是如何实现的。