XP提倡迭代周期越短越好(XP建議為一到兩周)，這是個(gè)不錯(cuò)的提議。在這么短的一個(gè)迭代周期內(nèi)，我們花在架構(gòu)設(shè)計(jì)上的時(shí)間可能就只有一兩個(gè)小時(shí)到半天的時(shí)間。這時(shí)候，會(huì)有一個(gè)很有意思的現(xiàn)象，你很難去區(qū)分架構(gòu)設(shè)計(jì)和設(shè)計(jì)的概念了。因?yàn)樵谶@么短的一個(gè)周期之內(nèi)，完成的需求數(shù)量是很少的，可能就只有一兩個(gè)用例或用戶素材。因此，這幾項(xiàng)需求的設(shè)計(jì)是不是屬于架構(gòu)設(shè)計(jì)呢?如果是的話，由于開發(fā)過程是由多次的迭代組成的，那么開發(fā)過程中的設(shè)計(jì)不都屬于架構(gòu)設(shè)計(jì)了嗎?我們說，架構(gòu)是一個(gè)相對(duì)的概念，是針對(duì)范圍而言的，在傳統(tǒng)的瀑布模型中，我們可以很容易的區(qū)分出架構(gòu)設(shè)計(jì)和普通設(shè)計(jì)，如果我們把一次迭代看作是一個(gè)單獨(dú)的生命周期，那么，普通的設(shè)計(jì)在這樣一個(gè)范圍之內(nèi)也就是架構(gòu)設(shè)計(jì)，他們并沒有什么兩樣。但是，迭代周期中的架構(gòu)設(shè)計(jì)是要遵循一定的原則的，這我們在下面還會(huì)提到。

　　我們希望迭代頻率越快越好，但是這還要根據(jù)現(xiàn)實(shí)的情況而定。比如數(shù)據(jù)倉庫項(xiàng)目，在項(xiàng)目的初期階段，我們不得不花費(fèi)大量的時(shí)間來進(jìn)行數(shù)據(jù)建模的工作，這其實(shí)也是一項(xiàng)專門針對(duì)數(shù)據(jù)的架構(gòu)設(shè)計(jì)，建立元數(shù)據(jù)，制定維，整理數(shù)據(jù)，這樣子的過程很難分為多次的迭代周期來實(shí)現(xiàn)。

　　可以說，如果一支開發(fā)團(tuán)隊(duì)沒有相關(guān)迭代的概念，那么這支團(tuán)隊(duì)要立刻實(shí)現(xiàn)時(shí)隔兩周迭代周期是非常困難的，，同時(shí)也是毫無意義的。就像我們在上面討論的，影響迭代周期的因素很多，以至于我們那無法對(duì)迭代周期進(jìn)行量化的定義。因此我們只能從定性的角度分析迭代周期的發(fā)展。

　　另一個(gè)了解迭代的方法是閱讀XP的相關(guān)資料，我認(rèn)為XP中關(guān)于迭代周期的使用是很不錯(cuò)的一種方法，只是他強(qiáng)調(diào)的如此短的迭代周期對(duì)于很多的軟件團(tuán)隊(duì)而言都是難以實(shí)現(xiàn)的。

　　迭代周期的引入一定是一個(gè)從粗糙到精確的過程。迭代的本質(zhì)其實(shí)是短周期的計(jì)劃，因此這也是迭代周期越短對(duì)我們越有好處的一大原因，因?yàn)闀r(shí)間縮短了，計(jì)劃的可預(yù)測性就增強(qiáng)了。我們知道，計(jì)劃的制定是依賴于已往的經(jīng)驗(yàn)，如果原先我們沒有制定計(jì)劃或細(xì)節(jié)計(jì)劃的經(jīng)驗(yàn)，那么我們的計(jì)劃就一定是非常粗糙，最后的誤差也一定很大。但是這沒有關(guān)系，每一次的計(jì)劃都會(huì)對(duì)下一次的計(jì)劃產(chǎn)生正面的影響，等到經(jīng)驗(yàn)足夠的時(shí)候，計(jì)劃將會(huì)非常的精確，最后的誤差也會(huì)很小。

　　迭代周期的確定需要依賴于單位工作量。單位工作量指的是一定時(shí)間內(nèi)你可以量化的最小的績效。最簡單的單位工作量是每位程序員一天的編碼行數(shù)�？上э@示往往比較殘酷，團(tuán)隊(duì)中不但有程序員的角色，還有設(shè)計(jì)師、測試人員、文檔制作人員等角色的存在，單純的編碼行數(shù)是不能夠作為唯一的統(tǒng)計(jì)依據(jù)的。同樣，只強(qiáng)調(diào)編碼行數(shù)，也會(huì)導(dǎo)致其它的問題，例如代碼質(zhì)量。為了保證統(tǒng)計(jì)的合理性，比較好的做法是一個(gè)團(tuán)隊(duì)實(shí)現(xiàn)某個(gè)功能所花費(fèi)的天數(shù)作為單位工作量。這里討論的內(nèi)容實(shí)際是軟件測量技術(shù)，如果有機(jī)會(huì)的話，再和大家探討這個(gè)問題。

　　我們應(yīng)用迭代方法的最大的目的就是為了穩(wěn)步的改進(jìn)軟件架構(gòu)。因此，我們需要了解架構(gòu)是如何在軟件開發(fā)的過程中不斷演進(jìn)的。在后面的文章中，我們會(huì)談到用Refactoring的方法來改進(jìn)軟件架構(gòu)，但是Refactoring的定義中強(qiáng)調(diào)，Refactoring必須在不修改代碼的外部功能的情況下進(jìn)行。對(duì)于架構(gòu)來說，我們可以近乎等價(jià)的認(rèn)為就是在外部接口不變的情況下對(duì)架構(gòu)進(jìn)行改進(jìn)。而在實(shí)際的開發(fā)中，除非非常有經(jīng)驗(yàn)，否則在軟件開發(fā)全過程中保持所有的軟件接口不變是一件非常困難的事情。因此，我們這里談的架構(gòu)的改進(jìn)雖然和Refactoring有類似之處，但還是有區(qū)別的。

　　軟件架構(gòu)的改進(jìn)在軟件開發(fā)過程會(huì)經(jīng)歷一個(gè)振蕩期，這個(gè)振蕩期可能橫跨了數(shù)個(gè)迭代周期，其間架構(gòu)的設(shè)計(jì)將會(huì)經(jīng)歷劇烈的變化，但最后一定會(huì)取向于平穩(wěn)。(如果項(xiàng)目后期沒有出現(xiàn)設(shè)計(jì)平穩(wěn)化的情況，那么很不幸，你的項(xiàng)目注定要失敗了，要么是時(shí)間的問題，要么就是需求的問題)。關(guān)鍵的問題在于，我們有沒有勇氣，在架構(gòu)需要改變的時(shí)候就毅然做出變化，而不是眼睜睜的看著問題變得越來越嚴(yán)重。最后的例子中，我們討論三個(gè)迭代周期，假設(shè)我們在第二個(gè)周期的時(shí)候拒絕對(duì)架構(gòu)進(jìn)行改變，那么第三個(gè)周期一定是有如噩夢一般。變化，才有可能成功。

　　我們知道變化的重要性，但沒有辦法知道變化的確切時(shí)間。不過我們可以從開發(fā)過程中嗅到架構(gòu)需要變化的氣味：當(dāng)程序中重復(fù)的代碼逐漸變多的時(shí)候，當(dāng)某些類變得格外的臃腫的時(shí)候，當(dāng)編碼人員的編碼速度開始下降的時(shí)候，當(dāng)需求出現(xiàn)大量的變動(dòng)的時(shí)候。