在軟件開發(fā)方面，架構(gòu)設(shè)計的作用不可諱言。中培偉業(yè)《軟件系統(tǒng)詳細(xì)設(shè)計最佳實踐》培訓(xùn)專家張老師指出，在傳統(tǒng)開發(fā)方法中，架構(gòu)設(shè)計是圍繞著設(shè)計文檔展開的。具體實施過程有如下特點：

l 預(yù)先設(shè)計。在實際開發(fā)工作開始前，少數(shù)架構(gòu)師們需要用相當(dāng)長的一段時間來進(jìn)行架構(gòu)設(shè)計和詳細(xì)設(shè)計，力求得到一個具有高度可擴(kuò)展性的良好架構(gòu)。產(chǎn)出為“概要設(shè)計文檔”和“詳細(xì)設(shè)計文檔”。根據(jù)項目規(guī)模，這個過程一般持續(xù)數(shù)周、數(shù)月甚至數(shù)年不等

l 短暫評估。架構(gòu)師產(chǎn)出的設(shè)計文檔要經(jīng)過架構(gòu)設(shè)計評審委員會或類似組織的評審，這個過程一般持續(xù)數(shù)天

l 依據(jù)設(shè)計進(jìn)行實現(xiàn)。經(jīng)過評審的設(shè)計會交到開發(fā)者手中，進(jìn)行實際的編程實現(xiàn)，這個過程往往以數(shù)月，甚至數(shù)年來計算。

思考傳統(tǒng)架構(gòu)設(shè)計方法，我們不禁要提出這樣的問題：

為什么傳統(tǒng)開發(fā)方法會如此重視前期預(yù)先架構(gòu)設(shè)計，以至于希望在實際開發(fā)前把架構(gòu)設(shè)計做到盡善盡美？

答案在于，在傳統(tǒng)的概念中，一旦設(shè)計成型，架構(gòu)是很難調(diào)整的。例如，傳統(tǒng)的軟件工程教科書中都會討論“架構(gòu)調(diào)整的成本”問題：如果在設(shè)計中實現(xiàn)一次修改的成本為1；在實現(xiàn)過程中相同修改的成本就是5～10；在測試、部署階段，同樣的修改成本將上升到50～100；維護(hù)階段同樣修改的成本更是成指數(shù)曲線上升。

這種策略存在一個根本問題：軟件的“擴(kuò)展”究竟會如何發(fā)生是很難預(yù)計的。面對這一困境，傳統(tǒng)開發(fā)方法的解決方案是繼續(xù)增加預(yù)先設(shè)計的時間和人力，但往往收效甚微。

傳統(tǒng)設(shè)計困境分析

傳統(tǒng)預(yù)先設(shè)計方法惡性循環(huán)的原因有三點，對應(yīng)上述實施過程的特點：

l 設(shè)計和實現(xiàn)脫節(jié)。設(shè)計評審團(tuán)專家一般不參與實際的軟件開發(fā)。基于經(jīng)驗的設(shè)計一方面無法得到實現(xiàn)的驗證；另一方面，當(dāng)需求發(fā)生變更時，無法隨之演進(jìn)。

l 評估的可靠性有限。對預(yù)先設(shè)計評估的只能基于已知的需求，而系統(tǒng)的可擴(kuò)展性是在應(yīng)對變更的需求時體現(xiàn)出來的，因此評估具有很大的局限性

l 實現(xiàn)者缺少對預(yù)先設(shè)計進(jìn)行修改的支持。當(dāng)預(yù)先設(shè)計不能滿足實際需求時，開發(fā)者或者修改設(shè)計，或者置需求變更不理，繼續(xù)沿預(yù)先設(shè)計開發(fā)。忽視需求變更的結(jié)果只能是系統(tǒng)無法滿足應(yīng)用（而開發(fā)者也可以將責(zé)任推到架構(gòu)師身上）；如果開發(fā)者根據(jù)需求修改設(shè)計，則預(yù)先設(shè)計不但事實上已經(jīng)成為浪費，而且已有的設(shè)計和實現(xiàn)往往更成會增加修改的難度。原因在于，如果預(yù)先設(shè)計的擴(kuò)展性沒有用到，則這些額外的擴(kuò)展性帶來的對當(dāng)前需求無用的復(fù)雜性，這些復(fù)雜性增加了理解、修改系統(tǒng)的難度。