上個禮拜，公司簽了一個新客戶，他們要求在我們在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了。