一個金融應用專案的總結 (轉)

worldblog發表於2007-12-12
一個金融應用專案的總結 (轉)[@more@]

我參與了一個金融應用專案,忙了好一陣子,停下來思考一下,覺得專案存在問題,想給領導提提建議,於是整理了一下思路,先請大家提提看法。

方面:我們部門在端的開發主要採用Borland C++Builder,初衷可能是考慮部門裡的開發人員大部分都對C比較熟悉,而C++相容C,也就是說可以在C++Builder中使用C,這當然有一定的好處,但由此帶來的問題也逐漸暴露出來。因為
C是程式導向的,很容易使我們用面向的開發工具進行程式導向的開發。
常見的情況是:在介面上放一些,設定一下屬性,然後開始對事件進行編碼,除了裡面的程式碼有了物件的方法還能看出點OO的痕跡,整個思路還是程式導向的。這樣,不但不能發揮物件導向的優勢,而且,由於Windows的事件觸發機制,使得系統的邏輯流程還不如用結構化的開發方法清晰。結果是程式碼複用性差,不好維護。

我覺得最主要的原因是缺乏對物件導向思想的理解與應用氛圍。就我個人體會,對,C++Builder等開發工具的應用可以分為3個層次,最常見的是能使用系統提供的控制元件進行程式設計,更高一層,能夠自己作控制元件,把常用的,通用的模組封裝成控制元件,以利於複用。最高層次就是在開發中融入物件導向的思想,進行物件導向設計,物件導向程式設計,實際上,到這一層已經跟語言的特性已經沒什麼關係了。
所以,我覺得有必要在開發人員中普及物件導向思想。
改進措施:
1。使他們意識到必要性(其實大部分人都知道物件導向的好處...)
2。創造學習氛圍,提供學習資料,內部培訓交流等方式
3。在實際應用中提高(需要評審,檢查機制來確保質量)


在設計方面:缺少富有物件導向設計的人員以及沒有架構設計師(Architect)的角色。任務的分配方式主要是由專案經理劃分好模組,初步規劃後,分給下面的開發人員設計,編碼,這樣,設計的質量過多依賴於開發人員的水平,並且缺少檢查評審機制,最終影響產品質量。
改進措施:
1。招聘或內部選拔架構設計師,由架構設計師負責系統的總體架構設計以及考慮系統的非功能性需求,如:Security
,Reliability,Performance等。
2。組織物件導向設計的學習培訓。如設計,設計原則,UML等
3。加強管理,確保評審制度的。由高階設計人員輔導、檢查設計人員的設計,同等水平的設計人員之間的互相評審
  與檢查。

 
在開發方法方面:我負責一個子系統的開發,在開發過程中,為了降低風險,以及給客戶作演示的需要,採用原型化開發方法。作原型時,為了趕時間,沒有很好的去規劃系統,也沒有注意編碼規則,命名規範等。實際上,作原型也不必花太多的功夫在這些時間上面,但前提是:後續的開發不能在原型的基礎上開發。但我違背了這個前提。導致了現在的程式碼
顯得很凌亂,需要花很多的精力去改進。
改進措施:
作原型與後續開發一定要分開。


 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-991758/,如需轉載,請註明出處,否則將追究法律責任。

相關文章