上个礼拜，公司签了一个新客户，他们要求在我们在summary报表假如更多的交易类型。我们的系统采用的是rave4.0，报表的layout（rave文件）存放在数据库中，使用时，用存储过程获取数据，然后填充到报表文件中，用户就可以浏览打印。整个过程很简单，可没想到，这就是我恶梦的开始。
首要的问题，是这个报表原始设计一塌糊涂，有大量的运算不是在存储过程中完成，而是在report里完成，而rave4.0提供的运算符功能极其简单，只能支持二元运算，稍微复杂一点的运算表达式都会牵连出一大堆的中间运算符和临时参数。当初的设计者把所有的参数都设成为project parameters，而且命名毫无规则可言，使得整个运算逻辑表达得像一锅粥。打个比方，我在报表的底部看到一个AdjustdeValue的显示字段，一看属性，是来自一个叫做AdjustedValuePG1的参数，但是这个参数是怎么算出来的呢？你不知道，你只知道它是一个project parameter，好，这就是说，我得浏览项目中的所有运算符的destination parameter，运气好的话，找个十几二十次就能找到，找到以后才是第一步，因为这个运算符的两个运算元素又是两个参数，好，继续重复第一步，就这样，重复在整个报表项目里scroll了半个小时，你发现原来这个adjustedValue是来自于一个5个变量的四则混合运算表达式。这算是运气好的，但是rave还提供了在程序里设置这些参数值的函数，比方说，我发现一个temp1的参数，我遍历了大大小小100多个运算符不止一次以后，终于发现原来这个参数是在程序里面设定的。虽然说这个设计问题主要责任在当初的设计人员身上，但是rave4.0
