前端工程之代码压缩

代码压缩在后端很少用到，在前端却成为一个必不可少的环节。
公司用的压缩工具是一个脚本，位于/utils目录，每次更改文件后，
都要进入这个目录，用./generate.do命令重新生成一下这个文件。
这个脚本是采用YUI compressor来压缩，用java来引入这个包，然后写各种钩子实现的。
很复杂，基本上前端人员是无法维护这个脚本的。
这个脚本已经写好了，对于前端人员来说只需要知道如何使用即可。
在项目中也确实如此，但直到有一天。
后端做了一个功能，他修改了些js,然后让我帮忙发布下这个js。
测试已经通过了，只需要发布代码到线上。
我按照惯例，发布上线了。
上线测试后发现有问题，一看js代码没改过来。
线上有问题，后端人员压力颇大，直接向测试说我这边没问题，是前端代码未更改过来。
我表示非常委屈啊，我是按照标准流程来做的。
随后我又重新试验了几次，发现问题依旧，然后找几个同事来帮忙，
他们都说很奇怪，不知为何会出现此问题。
我向后端反映了这个问题，我表示无能为力。
这时候后端人员开始发飙了，直接指责就是我的问题。
我感觉非常奇怪，出现问题了为什么首先追究是谁的问题，而不是寻求解决办法。
后来我实在没办法，主动去找团队的一个大牛帮忙。
看到这个问题后，大牛弄了一个多小时，终于搞定。
写了一行代码：

java -jar ./utils/yui...jar --type js webroot/....src.js --o js/webroot/...js

简单理解就是：不采用之前那个脚本来压缩，而采用手动来压缩。
问题是解决了，但为何不能用脚本来压缩，没有人知道为什么。
我只能猜测为：这个脚本写得有些问题了。
但已经没有人能维护这个脚本了。

神器来临

经过这次风波后，我想有没有更好的方法呢？
于是我发现了前端工程自动化神器：Grunt。
Grunt有很多插件，其中就有代码压缩：uglify。

grunt.loadNpmTasks('grunt-contrib-uglify');// 加载包含 "uglify" 任务的插件。

所有的这些插件都有配置选项，都可以自定义，非常地方便灵活。
而且脚本都是js写的，也非常适合前端来维护。
所以用java -jar 这种来压缩前端代码的方式可以退出历史潮流了。