考核系統快結束了，將此項目的經歷回憶如下，也小結一下，先談這個項目中值得提倡的地方：

1、在開發之前進行了完整的需求分析，形成了系統的需求文檔，需求文檔中最有用的部分感覺就是界面原型，還有系統的菜單，這樣給了用戶一個初步的直觀的印象，同時文檔中的一些對于界面原型的描述以及計算規則等內容在后期的開發中也起了指導作用。

2、在需求分析完成之后，進行了概要設計，包括完整的數據庫設計，這樣在后期的開發中對數據庫表結構方面沒有大的修改了，只是添加了一些表和視圖。

再談談項目中的缺點吧：

1、首先就說說需求文檔，雖說需求文檔寫了很多，大概有100頁左右（word），但由于一篇文檔中集中的內容太多，對于用戶來說只是關注了界面原型，系統菜單等部分，對于其它內容用戶關注度不高；同時由于篇幅太大，開發人員打開查看或者后續修改也比較麻煩。

對于以后的需求文檔是否可以這樣編寫：首先有一個正文，正文中包括大綱，然后將每一個具體的需求放在單獨的一個文檔中，最好能類似html鏈接那樣，這樣查看也方便，也一目了然。

原來用RobotHelp寫過幫助，照此看來，豈不可以用來寫需求文檔了，呵呵

2、再說數據庫設計，還不夠細致，很多應用場景由于設計的不夠細致，導致數據庫表也有所欠缺，因此對于以后的項目設計有兩個注意點：

a、加強應用場景設計，具體可以用流程圖，甚至序列圖描述清晰的業務流程，完善數據庫表設計。

b、要求一定先修改模型（這里指PowerDesigner中的數據庫設計），然后再去修改POJO類等具體代碼，最好不要先改代碼，再修改模型，這樣難免會有遺漏，時間久了，就會導致模型和代碼的不一致，慢慢的，模型文檔就沒有人看，也沒有人維護了。

c、順便提一下，模型文檔的好處一是方便后來者，二是可以方便的導出數據字典。

3、對于命名規范沒有在開發前考慮全面，雖然在開發前對命名規范有一定的規定，但是不夠全面，造成了后期開發中各人各人的命名有所偏差。

4、分層架構中的dao層和service層處理的不夠好，導致service層實際上是混雜了dao和service的功能，業務代碼不夠清晰。以后的項目考慮dao就是dao，提供數據訪問的操作，service層則提供業務處理方法，service與dao的關系應該是多對多的關系。

5、考核系統中使用了JSF/Richfaces做為表現層，好像不太好使，經常會出現多次重復訪問方法的問題，后續還需要加強對JSF的學習，避免類似問題。另外Richfaces在生成大數據量的頁面時，一個表格有1440行數據，頁面巨慢無比:(，后來沒有使用RichaFaces的表格，直接使用jstl+html標簽，速度倒是很快。

6、項目中的日志輸出、異常處理不夠明晰，這個和命名規范一樣應該在項目開始時給出清晰的思路，在具體開發中應該經常檢查。