Rainfinity ATS成功之道

Rainfinity ATS无疑是一个成功的ATS。它值得学习的地方不在于它的编码，而在于针对ATS这种特定软件，设计师在设计时做出的一些正确的决定对于我具有启发作用。

总的来说，RainfinityATS是KISS的又一个例证。Keep It Simple and Stupid(K.I.S.S)

1） 只关注系统最核心的功能。但对这个功能做非常充分的测试。RainfinityATS不想做瑞士军刀，而是只专注某一个功能的外科手术刀。设计任何ATS系统的时候我想都要把这个作为一个原则。如果测试的要求比较多，一个测试系统不能满足，那么宁愿另开炉灶，开发一个新的系统，也不要把所有的功能挤在一个系统里。

2） 强制要求一个特定的环境，而不是让自己聪明来适应环境。RainfinityATS的初始配置工作非常麻烦，因为很多东西都要为它准备好。但好处是一旦配置好了，就能稳定的运行。

3） 另外一个优点是充分利用了已有的工具，并且通过命令行和这些工具传递控制信息。这种方式是unix下面的惯用方式。它的好处是提高了模块间的独立性，相对于API调用。

即使如此，Rainfinity ATS里面还是有一些失败的设计。这些设计几乎在所有ATS系统中都可见。保持对这些失败之处的警惕对设计人员来说是很重要的。

1)在错误的地方实现一个功能

比如action group。Action group的出发点是好的，把action集合起来，定义为一个named group，然后直接引用此group即可。但是action group的问题是

action group的功能非常简单，也就是一些action名字的集合。没有必要专门的一个类来处理。而且它导入间接性影响了理解testcase。也就是它的好处并不能抵消它带来的缺点。

实际上action group的概念是有意义的，但它放在了错误的层内。它完全可以在testcase的层次来处理，而不用在ATS的框架里面。

2）仅仅因为头脑发热而实现一个功能

RainfinityATS里面还有一些脚本，比如到bugzilla查询bug的脚本。看得出来费了很多精力来开发，但几乎很少使用。因为即使亲自动手做这样的工作也是非常简单的。如果没有迫切的需要人们都懒得学习新的东西，所以使用率不高也在情理之中了。所以开发脚本的时候，如果它的用户是team所有的成员，那么一定不要头脑发热就开发，而是充分了解team成员的需求，在大部分人都有强烈的需求的情况下再动手。特别是这个脚本具有下面的特点的时候。

1） 开发此脚本需要较大的投入

2） 开发此脚本需要对已有的系统做一定的修改