低劣的設計,會使你走向泥潭,難以自拔
我進這個公司一年多一點了.剛進公司沒什么事做,所以經理就讓做一個小系統,為公司以后的需求作準備.
為了快速的完成任務,我也就沒有多考慮用最簡單,傳統的方式(jsp + javaBean)很快完成了項目.系統經過測試員測試通過 這樣我才放心了.
現在公司準備上線系統,這下可把我害慘了.系統寫了一年左右了,用戶的需求我都不記得了.此時,用戶又對系統提出了新的需求,要求修改.我沒有辦法,系統是我寫的,那么更新維護自然也是我的事情了.我只有拿出原來的文檔,重新整理思路,才把相關的需求回想起來.隨著時間的推移,經驗的積累,看到自己寫的那些代碼實在是難以忍受.現在要維護系統了,感覺是牽一發動全身,真是糟糕透了.當時寫出系統時還沾沾自喜,自己又搞定一個系統,很有成就感的.現在我看你還牛到那去.
回頭再審視自己做的設計,寫的代碼. 發現了不少問題.
1)層次混亂.我們經常說的表示層,業務邏輯層,持久層相互高耦合,沒有一個清晰的分層.系統的架構應當采用現在流行的框架.比如說
表示層用webwork,struts,spring mvs,jsf等等,
業務層(事務管理,,,)spring
持久層用hibernate,iBatis,,,,
2)沒有面向接口編程.整個系統中沒有見到一個接口.我還停留在面向類的編程.養成良好的編程習慣.
oop,aop讓你的系統有好的維護性,擴展性
3)業務實現細節,性能上存在問題.比如說:對基本信息的修改實現方式真糟糕.因為基本信息的屬性有40多個,它和另一個表是一對多的
關聯關系. 當時覺得那么多屬性,懶得用update一個一個得來更新,干脆把相關得信息(包括它關聯的另一個表的信息)刪除掉.這樣造成了很多不
必要的操作麻煩.你修改基本信息,為什么要去刪除它關聯表的信息,然后又要把它的信息添加進來.這不就是畫蛇添足嗎?先刪除,然后又添加,
一些不必要的操作,造成了性能的下降.系統的開發遵循簡單的設計.
4)業務操作混淆.添加新的基本信息與更新基本信息都放在同一個方法中.每一個業務方法對應一個操作.
5)系統不穩定.對系統要有好的單元測試,集成測試.
6)用戶操作不方便.要站在用戶的角度多考慮,那樣的操作是他們習慣的,他們想要的.
這樣的系統真是糟糕,難以維護,難以擴展,很難有好的性能.
我們開發的系統不能滿足于夠用,做出的系統要有好的可維護,可重用,可擴展性.
posted on 2006-01-05 17:19
Harryson 閱讀(311)
評論(0) 編輯 收藏 所屬分類:
SoftwareEngineering