XP提倡迭代周期越短越好(XP建議為一到兩周),這是個不錯的提議。在這么短的一個迭代周期內(nèi),我們花在架構(gòu)設(shè)計上的時間可能就只有一兩個小時到半天的時間。這時候,會有一個很有意思的現(xiàn)象,你很難去區(qū)分架構(gòu)設(shè)計和設(shè)計的概念了。因為在這么短的一個周期之內(nèi),完成的需求數(shù)量是很少的,可能就只有一兩個用例或用戶素材。因此,這幾項需求的設(shè)計是不是屬于架構(gòu)設(shè)計呢?如果是的話,由于開發(fā)過程是由多次的迭代組成的,那么開發(fā)過程中的設(shè)計不都屬于架構(gòu)設(shè)計了嗎?我們說,架構(gòu)是一個相對的概念,是針對范圍而言的,在傳統(tǒng)的瀑布模型中,我們可以很容易的區(qū)分出架構(gòu)設(shè)計和普通設(shè)計,如果我們把一次迭代看作是一個單獨的生命周期,那么,普通的設(shè)計在這樣一個范圍之內(nèi)也就是架構(gòu)設(shè)計,他們并沒有什么兩樣。但是,迭代周期中的架構(gòu)設(shè)計是要遵循一定的原則的,這我們在下面還會提到。
我們希望迭代頻率越快越好,但是這還要根據(jù)現(xiàn)實的情況而定。比如數(shù)據(jù)倉庫項目,在項目的初期階段,我們不得不花費大量的時間來進行數(shù)據(jù)建模的工作,這其實也是一項專門針對數(shù)據(jù)的架構(gòu)設(shè)計,建立元數(shù)據(jù),制定維,整理數(shù)據(jù),這樣子的過程很難分為多次的迭代周期來實現(xiàn)。
可以說,如果一支開發(fā)團隊沒有相關(guān)迭代的概念,那么這支團隊要立刻實現(xiàn)時隔兩周迭代周期是非常困難的,,同時也是毫無意義的。就像我們在上面討論的,影響迭代周期的因素很多,以至于我們那無法對迭代周期進行量化的定義。因此我們只能從定性的角度分析迭代周期的發(fā)展。
另一個了解迭代的方法是閱讀XP的相關(guān)資料,我認為XP中關(guān)于迭代周期的使用是很不錯的一種方法,只是他強調(diào)的如此短的迭代周期對于很多的軟件團隊而言都是難以實現(xiàn)的。
迭代周期的引入一定是一個從粗糙到精確的過程。迭代的本質(zhì)其實是短周期的計劃,因此這也是迭代周期越短對我們越有好處的一大原因,因為時間縮短了,計劃的可預(yù)測性就增強了。我們知道,計劃的制定是依賴于已往的經(jīng)驗,如果原先我們沒有制定計劃或細節(jié)計劃的經(jīng)驗,那么我們的計劃就一定是非常粗糙,最后的誤差也一定很大。但是這沒有關(guān)系,每一次的計劃都會對下一次的計劃產(chǎn)生正面的影響,等到經(jīng)驗足夠的時候,計劃將會非常的精確,最后的誤差也會很小。
迭代周期的確定需要依賴于單位工作量。單位工作量指的是一定時間內(nèi)你可以量化的最小的績效。最簡單的單位工作量是每位程序員一天的編碼行數(shù)?上э@示往往比較殘酷,團隊中不但有程序員的角色,還有設(shè)計師、測試人員、文檔制作人員等角色的存在,單純的編碼行數(shù)是不能夠作為唯一的統(tǒng)計依據(jù)的。同樣,只強調(diào)編碼行數(shù),也會導(dǎo)致其它的問題,例如代碼質(zhì)量。為了保證統(tǒng)計的合理性,比較好的做法是一個團隊實現(xiàn)某個功能所花費的天數(shù)作為單位工作量。這里討論的內(nèi)容實際是軟件測量技術(shù),如果有機會的話,再和大家探討這個問題。
我們應(yīng)用迭代方法的最大的目的就是為了穩(wěn)步的改進軟件架構(gòu)。因此,我們需要了解架構(gòu)是如何在軟件開發(fā)的過程中不斷演進的。在后面的文章中,我們會談到用Refactoring的方法來改進軟件架構(gòu),但是Refactoring的定義中強調(diào),Refactoring必須在不修改代碼的外部功能的情況下進行。對于架構(gòu)來說,我們可以近乎等價的認為就是在外部接口不變的情況下對架構(gòu)進行改進。而在實際的開發(fā)中,除非非常有經(jīng)驗,否則在軟件開發(fā)全過程中保持所有的軟件接口不變是一件非常困難的事情。因此,我們這里談的架構(gòu)的改進雖然和Refactoring有類似之處,但還是有區(qū)別的。
軟件架構(gòu)的改進在軟件開發(fā)過程會經(jīng)歷一個振蕩期,這個振蕩期可能橫跨了數(shù)個迭代周期,其間架構(gòu)的設(shè)計將會經(jīng)歷劇烈的變化,但最后一定會取向于平穩(wěn)。(如果項目后期沒有出現(xiàn)設(shè)計平穩(wěn)化的情況,那么很不幸,你的項目注定要失敗了,要么是時間的問題,要么就是需求的問題)。關(guān)鍵的問題在于,我們有沒有勇氣,在架構(gòu)需要改變的時候就毅然做出變化,而不是眼睜睜的看著問題變得越來越嚴重。最后的例子中,我們討論三個迭代周期,假設(shè)我們在第二個周期的時候拒絕對架構(gòu)進行改變,那么第三個周期一定是有如噩夢一般。變化,才有可能成功。
我們知道變化的重要性,但沒有辦法知道變化的確切時間。不過我們可以從開發(fā)過程中嗅到架構(gòu)需要變化的氣味:當(dāng)程序中重復(fù)的代碼逐漸變多的時候,當(dāng)某些類變得格外的臃腫的時候,當(dāng)編碼人員的編碼速度開始下降的時候,當(dāng)需求出現(xiàn)大量的變動的時候。
相關(guān)推薦:2010年軟件水平考試程序員考試備考資料北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |