前不久以系統設計的角色參與了一個小型項目,下面總結一下項目開發過程中的感受.
作者:jazzy 時間:2005-08-01 版本:1.0
中小型項目,復雜度不高,開發進度緊迫.
在這樣的項目特點和時間節點的要求下,項目組為了加快開發進度,采取了通過對以前一個有一定類似度的項目二次改造的方法來構建新系統.這樣的開發方式在項目開發中很常見,實際就是對項目級別的軟件復用.它是技術部知識積累的價值體現,無論從節約成本和提高工作效率來說都是大有裨益的.這樣的開發方式,至少從現象上來說,是很令人振奮的:一個中小型應用,通過對其他項目的復用,在兩三天之內就可以完成項目原型.十幾天后整個系統就可以上線試運行.
但是,在看似光鮮的表象背后卻隱藏著難以被人察覺的污垢.
對于設計人員,在這樣的情況下做進一步的設計必需要充分了解前一個項目的結構.他會這樣說:前一個項目的說明文檔在哪里?數據結構說明在哪里?天那!竟然什么文檔都沒有,我還是通過代碼走查來猜測原有系統的設計意圖吧!oh!my god!
對于開發人員,進行開發需要閱讀原開發人員的代碼.他會這樣說:為什么沒有注釋?這個變量命名代表什么意義?這個問題原系統沒辦法實現,我還是用自己的方式來解決吧!oh!my god!
對于領導來說,不必關心開發過程,只要關心在規定的時間節點有沒有達成任務目標.這樣一來,工作壓力被堆砌在設計和開發人員身上,尤以編寫最終代碼的開發人員為重.
在以往的工作經驗中,我也以開發人員的角色參加過這樣的項目.切身體會過這樣開發的難處.當時我的項目原有開發人員離職.我為了實現一點小小的改動,不得不跟蹤查閱整個系統的代碼.這時的開發人員會十分抱怨原系統代碼的丑陋,而且原系統中原有的一些優秀設計思想和閃光點也在這樣的修改過程中被埋沒甚至消逝了.
當然了,A項目被修改成B項目,B項目將來也可能會被修改成C項目,C項目又修改成D項目.新的設計開發人員,又會產生新的,類似的抱怨.在一次次的修改和抱怨聲中,系統的質量越來越差,效率越來越低,bug越來越多,代碼中到處充斥著壞味道.重構吧?是時候了.可是誰又愿意接手這樣無序混亂,高熵的代碼呢?
問題的本質在哪里?
問題的本質似乎是顯而易見的.原有系統的文檔不齊全,不規范,不一致,給后續的復用帶來了理解上的困難.進而這種困難會映射到后續的每一個項目.但是解決這樣的問題是件棘手的事情,每個人都知道文檔的重要性,但是介于項目的開發進度的要求,大多數時候,根本沒有時間去寫詳盡的文檔.
換個角度,假設有一個項目的文檔齊全甚至是完美,任何人看一眼就能立刻理解系統的計劃的架構層次,功能結構那么這樣的項目又能為軟件的復用提供多大幫助呢?項目僅僅是項目,從軟件復用的角度去看,做項目級別的軟件復用本身就是不妥當的.項目中包含了太多和業務需求的耦合.這種耦合在復用過程中會侵蝕到系統的每一個角落.
可見,問題的本質在于軟件重用的粒度和方法.
基于以上對問題的分析,我們發現我們似乎是需要一個類似普元EOS的面向構件開發平臺,任何復用都面向構件.但是相信包括我在內的大多數熱愛技術的開發人員都不會喜歡這樣封裝了太多底層細節的開發平臺.而且從技術細節來說EOS采用XML總線而帶來的性能損耗也被牛人們所不齒.可是自行開發一個這樣類似平臺的成本又巨大,技術復雜度也極高.顯然是不能接受的.
所以改進建議只能從如下幾個方面提出
1,加強知識積累
2,提高文檔質量
3,提供開發庫
提供工具級別的復用.開發庫中提供細微粒度的工具包,例如鏈接池,mail工具包,報表工具包,ftp工具包,excel文件操作工具包,圖表生成工具包,常用javascript組件等等.通過平時項目的經驗積累來更新開發庫,也可以有專人開發/維護和推廣.
文章寫到這里就結束了,可是又覺得僅僅采用工具級別的復用并不能針對問題的本質,有點指標不治本的感覺.真正合適的復用粒度到底應該如何把握?這仍然是一個需要認真考慮的問題......