前端工程化-思考入门

做事情嘛总要有个目标；工作嘛，总要追求效率，规范，重用，可维护，毕竟谁不想工作上少花些时间，装逼（大雾）上多花些时间呢。废话不多说，下面开始装逼，装的不好请不要贱笑。

1，项目开始

例如新建一个项目：project，下面该做什么呢？一般来说就是搭建脚手架了，通常的做法呢：

A方案：

自己先把环境配置好，一个文件夹一个文件夹的建，一个配置文件一个配置文件的写，然后再把需要的js库啊什么的一个个的搞过来，其它的有需要的话可以随着项目的进行而添加

B方案：

使用自己曾经的脚手架或者别人的，当然，可能还需要修修改改

C方案：

如果只需要一个配置文件，自己只需要把里面自己需要的东西写上去，一条命令下来，该建的文件夹建好了，需要的js库下载好了，将来再需要其它文件的时候只需要加上去，然后再执行一遍命令就可以，岂不美哉。

其它方案：

抱歉其它方案这个逼我暂时还装不下去，这里就留给其他人吧

那么我们就这个【C方案】进行一下思考，这里我选择了js文件作为配置文件，为什么呢？因为别人都选择的js文件，而且，js文件可以读写其它文件啊

假如我们新建一个autoformat.js,这个文件应该写些什么呢？

这里就应该回归我们的需求：

1，可以创建我们需要创建的文件夹
2，可以自动下载我们需要下载的js库
3，自动安装需要的环境依赖
4，如果将来这个文件有更新，可以再次执行命令，不会冲突

OK，需求明确了，那么，我们怎么才能执行这些命令呢，通过什么方式来执行呢？

目的很明确，就是执行配置文件autoformat.js,怎么执行呢？额，因为别人一般都素通过命令执行的，所以咱们这里也通过命令执行。

假如我们搞一个最简单的:

node autoformat.js

这样就执行了，

或者逼格高一点,执行：autoformat  [taskname]

执行命令的方式大概确定了，那么来看一下需求怎么实现：

1，可以创建我们需要创建的文件夹

直接通过js在pc上创建文件夹不太现实，我们貌似也只能通过命令行来创建，
通过js来调用命令行，还是可以实现的。
这方面有现成的轮子，我们就不要自己造了。只是需要安装一下依赖。

2，可以自动下载我们需要下载的js库

同上，借助别人造好的轮子，下载个文件什么的还是不成问题的

3，自动安装需要的环境依赖

话说我们平时安装依赖不就是：

npm install 

然后我们的配置文件，package.json里面的依赖项就会自动安装了，
所以我们只要执行这个命令就行了，
至于依赖项，不就是我们前面选择的别人的轮子嘛

4，如果将来这个文件有更新，可以再次执行命令，不会冲突

这个嘛，不就是一个判断，甚至你可以直接覆盖之前的依赖项，
不过考虑到有时候自己会去修改js库，或者有时候误删除依赖，
这里可以配置为一个‘是否’覆盖安装的选项

到了这里，我们发现这些需求都是可以实现的，那么下面就需要进行技术选型了

考虑到当前系统是windows（mac买不起，linux这个逼格太高），
那么就要选择能执行dos命令的插件了，
都说windows下这个坑太多，但是咱也只能义无反顾的往里面跳了

OK，假设第一步已经完成了，好吧，实在是这里写太多了，
这才第一步自动构建生成项目，所以暂时放过，回头补充。

2，项目进行

项目进行的时候注意代码的 模块划分 和 预编译语言 以及 UI框架 的使用，
比如less(css),coffeescript(js)，HTML模板语言等

项目进行的时候一般有什么需求：

1，代码的版本控制这个肯定是需要的，默认是git，（svn还是算了吧）
2，代码的压缩合并这个也是必须的（这个也可以发布时做，但难免有时用到）
3，代码的测试和数据调试也免不了
4，添加新的插件或工具库
5，以上都是必须的，这些东西如果都通过命令行执行，那就算是比较工程化了吧

其实这一步已经有很多工具做过了，可能只做了一部分比如grunt,gulp等,express，fis3等，所以略过不提。

3，项目发布

项目要发布了，有什么需求：

1，发布的时候能不能一键发布呢，测试环境和正式环境同时更新
2，考虑到缓存，所以文件的后缀名用上hash值会不会更好
3，发布的时候最好发布出来一个新的文件，而不是在源码上修修改改
4，图片需要hash值和合并吗？

这一步其实也有人做了，比如fis3，webpack等,所以也简单略过。

最后

写到最后发现好像还没有什么工具能够 ‘一条龙服务到底’，做第一步的工具好像没什么太有名气的。
当然，我坐井观天，肯定只能看到一小片，这里只是一些思考总结，也是个人努力的方向，希望有一天我这一小片天空也能被洒下一片清凉。