用面向对象的思想改造ant script

用面向对象的思想改造ant script


三年前，我们的项目处于最紧张的时候，QA的头离职了，没有办法，项目经理把所有遗留的项目脚本全部委托我来管，谁叫我平时写那么多脚本呢？

这些脚本主要的作用是自动编译，压缩，打包，发布，主要是用ant script写的，整个系统有好几个子项目，比如基于hibernate，Jboss和J2EE的服务器端，基于Jquery和HTML的前端，专门为智能手机写的前端，数据挖掘和分析的模块等。

接手之后，发现前任还是做了不少工作，但他显然没有掌握面向对象的编程思想的精髓，喜欢在主控程序里直接完成子项目的任务，而且没有太多考虑脚本本身的测试问题，脚本又是在Hudson里面运行的，结果搞得整个系统关系复杂，错误很多，我猜测这也是他离职的原因之一。

闲话少说，言归正传。我们都知道面向对象是对付软件复杂性的常用法宝和银蛋，这里马上就会有道友跳出来讥讽我：你那个脚本根本不是面向对象的语言，别扯了。

那我举个例子把，你买了一台洗衣机，你知道按面板上的按钮就能洗衣服，因为某种原因，洗衣机周围的机壳现在全部被拆掉，但你知道它是个洗衣机，你仍然只按面板上的按钮，从不把手伸到洗衣机里面去。你仍然是相对安全的。
面向对象的语言就像那个有壳的洗衣机，它本身就有好的保护，非面向对象的语言，只要记住别把手伸进去，只操作面板上的按钮，仍然是个好用安全的洗衣机。

再次言归正传，我首先定义好每个子项目的接口，无非就是make, clean, deploy等，主控程序就负责准备环境，比如清理数据库，启动停止服务器，下载源程序等，然后call相应的子项目的任务完成相应的工作。所以我的第一个改造就是把各个任务归位到相应的子项目中去。

然后再来谈谈封装的问题，ant的Script传统上用target以及依赖来进行模块化，这样有个缺点，所有的target都对外开放，你不想暴露的底层target外面也能看见，所以我研究了一下，发现可以用macrodef来代替底层的target，至于依赖关系，大部分可以通过对生成的目标文件或状态标识变量来判断。所以我的第二个任务是把底层的大部分target改造成macrodef。

Macrodef其实更像一个函数，有接口变量。所以我也把大部分全局变量改造成局部变量，不是吗，缩小变量和函数的作用域也是面向对象的基本法宝之一。

这样改造之后，target就变成了子项目对外的接口，macrodef就变成了内部实现，很好地体现了封装性。改造完成之后，整个脚本更加容易被理解，有了更好的可维护性，更容易被测试，错误大大减少。但请记住，这是一个没有壳子的洗衣机，所以我把一些基本准则制定成军规，发给每一个可能写脚本的程序员。

改造完成之后，性能有所下降，估计下降了大约3％。没有关系，我们从算法上改进，我发现这里面最重的一个任务是压缩加密javascript代码，而这个任务与其他任务没有冲突，所以把它提升到与其他任务并行运算（ant parallel），现在是面向对象的，这样一个改动很简单，改造完成之后，整个过程所需时间一下子少了一小半。

任务完成，收工，报告给项目经理，他说：哇操。