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