項目已經進入最後的測試階段，而且這一次客戶要求很嚴格，JUnit 也要提交整個測試的報告。
由於這個項目比較大，差不多有40個人參與了這個項目，而幾乎有一半的人只是臨時幫忙，他們留下的代碼由於一些原因，導致後面修改的人幾乎不能修改，只能推倒按自己的方式重寫。
這個項目的第一期是做參數維護部分。每個參數都要進行增刪改查。而且每個模塊都是分爲三個頁面。
系統的架構是：
數據庫層(由Hibernate生成映射文件)：XXXData.java、XXXDataId.java、XXXTemp.java
中間層：XXXDao.java
邏輯層：XXXService.java、XXXDBean.java、XXXVO.java
顯示層：XXX.jsp、XXXAdd.jsp、XXXAud.jsp
其中Data、Temp、VO用於封裝數據。
Dao跟數據庫打交道，所有的增刪改查都在Dao中完成。
Service用於處理所有的事務，而DBean只做一個數據傳遞者的角色，從頁面收集數據，然後送到Service處理，如果Service 需要通過傳過來的數據作爲參數訪問數據庫，則Service直接調用Dao中的方法，然後Service將處理後的數據返回給DBean，DBean再將結果通過jsp顯示出來。
這裏查詢至少有兩種處理方法，用VO封裝數據和用Data封裝數據。計較好的一種方法是用VO封裝數據，這樣不用考慮Data 中的DataId，而且可以在VO中添加字段。
但是，由於我們這個項目沒有真正意義上的架構師，系統的實現方式並沒有統一，這就給後面維護的人員帶來了很大的麻煩。特別是這個項目的PM也是第一次帶隊，沒有多少經驗。
其實這個項目所用到的技術都不難，技術含量不高。但是整個項目很大，光參數維護就有30多個模塊。如果這些模塊有10個以上的人完成（幾乎就是這樣），而最後維護的人只有1~2個，則維護起來會非常吃力。如果一開始就由一個很有經驗的人寫一個模板，然後每一個都按照相同的方式實現，最後出錯的概率會很低，而且維護起來也會非常輕鬆。
我就是這兩個倒黴的維護的人之一，沒有辦法，只能將別人的實現方式改過來，改成自己的實現方式。我們這個項目延期了兩週，如果一開始就規劃好，肯定不會延期這麼多，下面的人也不會這麼累了。