上个礼拜，公司签了一个新客户，他们要求在我们在summary报表假如更多的交易类型。我们的系统采用的是rave4.0，报表的layout（rave文件）存放在数据库中，使用时，用存储过程获取数据，然后填充到报表文件中，用户就可以浏览打印。整个过程很简单，可没想到，这就是我恶梦的开始。
首要的问题，是这个报表原始设计一塌糊涂，有大量的运算不是在存储过程中完成，而是在report里完成，而rave4.0提供的运算符功能极其简单，只能支持二元运算，稍微复杂一点的运算表达式都会牵连出一大堆的中间运算符和临时参数。当初的设计者把所有的参数都设成为project parameters，而且命名毫无规则可言，使得整个运算逻辑表达得像一锅粥。打个比方，我在报表的底部看到一个AdjustdeValue的显示字段，一看属性，是来自一个叫做AdjustedValuePG1的参数，但是这个参数是怎么算出来的呢？你不知道，你只知道它是一个project parameter，好，这就是说，我得浏览项目中的所有运算符的destination parameter，运气好的话，找个十几二十次就能找到，找到以后才是第一步，因为这个运算符的两个运算元素又是两个参数，好，继续重复第一步，就这样，重复在整个报表项目里scroll了半个小时，你发现原来这个adjustedValue是来自于一个5个变量的四则混合运算表达式。这算是运气好的，但是rave还提供了在程序里设置这些参数值的函数，比方说，我发现一个temp1的参数，我遍历了大大小小100多个运算符不止一次以后，终于发现原来这个参数是在程序里面设定的。虽然说这个设计问题主要责任在当初的设计人员身上，但是rave4.0小儿科的运算功能和及其简易的内部结构也是一个重要诱因。
其次，rave4.0的界面非常不好用，最简单的例子就是，在对象属性框里居然不支持Ctrl+C和Ctrl+P，简直荒谬。而且，整个界面无法体现出个个元素之间的关系，也没有提供能够快速访问相关元素的功能，所有的浏览只能手动在整个项目结构书中一点一点寻找。
在花了3天时间搞清楚了大部分运算逻辑以后，我决定把整个report推倒重来。这是我第一次从头设计报表，但是经过这段时间的琢磨，我觉得报表设计需要遵循几个原则。
1． 我认为rave只适合做纯粹的格式控制，所有的数据都必须在调用报表之前准备好。（事实上，我认为所有的报表设计都应该这么做，必须用某种方式把运算逻辑和格式控制分离，否则，一旦需要更换报表组件或者调整运算逻辑，后继人员将会花费大量的时间来pick up）
2． 元素命名一定要遵循某个统一规范，这个更是软件开发各个环节需要遵循的一大基本规则，基本上，在这一条上屡教不改者，就可以考虑直接fire了。因为这种人在团队中待的时间越长，给整个团队开发带来的危害就越大。
3． 报表要具备一定的扩充能力，像我对付的那个报表，因为当初只支持两个类型，竟然在所有求和的运算中都用加法运算符代替了求和运算符，结果，一旦要增加一个新类型，就必须重做所有的求和运算。而事实上，如果能很好地做到第1部分，第3部分的是现实不费吹灰之力的，与在rave中相比，在程序代码或者存储过程中修改一下计算逻辑简直就是天堂里的工作。
我承认，这几天我遇到的问题不完全是rave的问题，里面有大量的原始设计问题，但是，rave仍然给我留下了很差的印象，我想，如果以后我有选择，我是不会再碰rave了。
