如何更好地進(jìn)行軟件架構(gòu)設(shè)計，這是軟件工程領(lǐng)域中一個永恒的重點話題。過去幾十年來，國際軟件工程界在軟件架構(gòu)設(shè)計方面已經(jīng)獲得了長足發(fā)展，大量圖書、文章和文獻(xiàn)記載了這方面的成熟經(jīng)驗與成果。軟件架構(gòu)設(shè)計往往是一件非常復(fù)雜的工作，涉及到很多細(xì)節(jié)和方方面面，可探討的話題也非常之多。囿于篇幅限制，以下只能根據(jù)筆者個人理解，遴選出軟件架構(gòu)設(shè)計的個別要點，結(jié)合當(dāng)前流行的敏捷軟件工程思想，與大家分享一下自己在軟件架構(gòu)設(shè)計方面的心得和體會。

    架構(gòu)決定成敗

    軟件架構(gòu)是軟件產(chǎn)品、軟件系統(tǒng)設(shè)計當(dāng)中的主體結(jié)構(gòu)和主要矛盾。任何軟件都有架構(gòu)，哪怕一段短小的HelloWorld程序。軟件架構(gòu)設(shè)計的成敗決定了軟件產(chǎn)品和系統(tǒng)研發(fā)的成敗。軟件架構(gòu)自身所具有的屬性和特點，決定了軟件架構(gòu)設(shè)計的復(fù)雜性和難度。

    這幾年流行一個說法（管理諺語）：“細(xì)節(jié)決定成敗”，這句話其實只說對了一半。細(xì)節(jié)確實很重要，很多項目、產(chǎn)品就輸在細(xì)節(jié)的執(zhí)行上。一方面，戰(zhàn)術(shù)細(xì)節(jié)固然很重要，但另一方面，戰(zhàn)略全局也同樣重要，對應(yīng)的我們可以說：“戰(zhàn)略決定成敗”。戰(zhàn)略性失敗，就好比下一盤圍棋，局部下得再漂亮、再凌厲，如果罔顧大盤，己方連空都不夠了，還有官子（細(xì)節(jié)）獲勝的機(jī)會嗎？必然是中盤告負(fù)。

    類似地，正確的軟件架構(gòu)設(shè)計，應(yīng)該既包括戰(zhàn)略全局上的設(shè)計，也包括戰(zhàn)術(shù)細(xì)節(jié)（關(guān)鍵路徑）上的設(shè)計。有一種錯誤的觀點認(rèn)為，軟件架構(gòu)設(shè)計只要分分層和包，畫一個大體的輪廓草圖，就完事了。這種“紙上談兵”型的架構(gòu)師行為是非常有害的。事實上，既然軟件架構(gòu)是軟件建筑的主體結(jié)構(gòu)、隱蔽工程、承重墻和要害部位，那么軟件架構(gòu)也必然要落實到實際的算法和代碼，不但要有實現(xiàn)代碼，還要包括對這部分架構(gòu)進(jìn)行測試的代碼，以保證獲得高質(zhì)量的、滿足各種功能和非功能質(zhì)量屬性要求的架構(gòu)。除了完成概念、模型設(shè)計外，軟件架構(gòu)師一定要參與實際的編碼、測試和調(diào)試，做一位真正的hands-on practitioner，這已經(jīng)成為了敏捷軟件工程所倡導(dǎo)的主流文化。

    兩個架構(gòu)

    我們在日常的軟件產(chǎn)品和系統(tǒng)開發(fā)中，實際上會遇到兩種、兩個部分的軟件架構(gòu)，即待開發(fā)的應(yīng)用部分的軟件架構(gòu)（簡稱“應(yīng)用架構(gòu)”），以及既有的基礎(chǔ)平臺部分的軟件架構(gòu)（簡稱“基礎(chǔ)架構(gòu)”）。這兩部分架構(gòu)之間是互為依賴、相輔相成的關(guān)系，它們共同組成了整個軟件產(chǎn)品和系統(tǒng)的架構(gòu)。

    基礎(chǔ)架構(gòu)的例子包括：.NET和J2EE等主流的基礎(chǔ)平臺和各種公共應(yīng)用框架，由基礎(chǔ)庫API、對象模型、事件模型、各種開發(fā)和應(yīng)用的擴(kuò)展規(guī)則等內(nèi)容組成。我們只有熟悉基礎(chǔ)架構(gòu)的構(gòu)造細(xì)節(jié)、應(yīng)用機(jī)理，才能有效地開發(fā)出高質(zhì)量、高性能的上層應(yīng)用。然而，開發(fā)一個面向最終用戶的軟件應(yīng)用系統(tǒng)和產(chǎn)品，僅僅掌握一般的計算機(jī)高級編程語言知識和基礎(chǔ)平臺架構(gòu)、API的使用知識顯然是不夠的，我們還需要根據(jù)客戶應(yīng)用的類型和特點，在基礎(chǔ)架構(gòu)之上，設(shè)計出符合用戶要求的高質(zhì)量應(yīng)用軟件。

    熟悉OOA、OOD抽象建模技術(shù)、設(shè)計原則以及架構(gòu)模式和設(shè)計模式等等方法技術(shù)，不但有助于我們更好地理解和利用基礎(chǔ)平臺架構(gòu)，也有助于我們設(shè)計開發(fā)出更高質(zhì)量的應(yīng)用軟件架構(gòu)。

    風(fēng)險驅(qū)動、敏捷迭代的架構(gòu)設(shè)計與開發(fā)

    軟件架構(gòu)將隨著軟件產(chǎn)品和系統(tǒng)的生命周期而演化，其生命期往往超過了一個項目、一次發(fā)布，甚至有可能長達(dá)數(shù)年之久，因而軟件架構(gòu)無論對于客戶還是開發(fā)商來說都是一項極其重要的資產(chǎn)。

    軟件架構(gòu)的設(shè)計應(yīng)該遵循什么樣的開發(fā)過程？或者說，有沒有更好的、成熟的軟件架構(gòu)設(shè)計和開發(fā)過程？回答是，21世紀(jì)的軟件架構(gòu)設(shè)計應(yīng)該優(yōu)先采用敏捷迭代的開發(fā)方式和方法。與傳統(tǒng)做法不同，敏捷迭代開發(fā)主張軟件架構(gòu)采用演進(jìn)式設(shè)計（evolutionary design），一個軟件產(chǎn)品或系統(tǒng)的架構(gòu)是通過多次迭代，乃至多次發(fā)布，在開發(fā)生命周期中逐步建立和完善起來的。

    好的軟件架構(gòu)不是一蹴而就的。在架構(gòu)設(shè)計開發(fā)過程中，我們應(yīng)該盡量避免瀑布式思維，通過一個“架構(gòu)設(shè)計階段”來完成系統(tǒng)的架構(gòu)設(shè)計乃至詳細(xì)設(shè)計，然后再根據(jù)架構(gòu)圖紙和模型，在“編碼實現(xiàn)階段”按圖索驥進(jìn)行架構(gòu)的編碼與實現(xiàn)。這種傳統(tǒng)做法的錯誤在于認(rèn)為軟件架構(gòu)就是圖紙上的模型，而不是真正可以高質(zhì)量執(zhí)行的源代碼。幾十年的軟件工程實踐表明，沒有經(jīng)過代碼實現(xiàn)、測試、用戶確認(rèn)過的架構(gòu)設(shè)計，往往會存在著不可靠的臆想、猜測和過度設(shè)計、過度工程，極易造成浪費和返工，導(dǎo)致較高的失敗率。

    風(fēng)險是任何可能阻礙和導(dǎo)致軟件產(chǎn)品/系統(tǒng)研發(fā)失敗的潛在因素和問題。軟件架構(gòu)是軟件產(chǎn)品和系統(tǒng)研發(fā)的主要矛盾和主要技術(shù)風(fēng)險，軟件架構(gòu)的質(zhì)量決定了整個軟件系統(tǒng)和產(chǎn)品的質(zhì)量。不確定性往往是軟件架構(gòu)設(shè)計當(dāng)中一種最大的潛在風(fēng)險。因此，軟件架構(gòu)的設(shè)計與開發(fā)應(yīng)該遵循風(fēng)險驅(qū)動的原則，在整個開發(fā)生命周期內(nèi)至始至終維護(hù)一張風(fēng)險問題清單，隨著迭代的前進(jìn)，根據(jù)風(fēng)險的實時動態(tài)變化，首先化解和處理最主要的架構(gòu)風(fēng)險，再依次化解和處理次要的架構(gòu)風(fēng)險。

    架構(gòu)設(shè)計的可視化建模

    軟件架構(gòu)設(shè)計的難度源于軟件設(shè)計問題本身的復(fù)雜性，一個復(fù)雜的軟件系統(tǒng)往往存在大量復(fù)雜的、難于被人類所理解的細(xì)節(jié)和不確定因素。抽象與建模是人類自誕生以來就已掌握的理解復(fù)雜事物的方法，因而人類所從事的軟件設(shè)計工作本質(zhì)上也是一個不斷建模的過程。我們可以通過各種抽象的模型和視圖，從各個不同層次、宏觀和微觀的角度來理解復(fù)雜的軟件架構(gòu)，以保證作出正確和有效的設(shè)計。

    有人認(rèn)為：“軟件架構(gòu)就是源代碼（source codes）”以及“源代碼就是設(shè)計”。這種說法其實是片面的。什么是真正的軟件？我們知道，最終可以在電腦上執(zhí)行的真正的軟件其實是二進(jìn)制代碼0和1，借助編譯器我們把高級編程語言翻譯成底層的匯編語言、機(jī)器語言等，沒有人能直接、完整地看到二進(jìn)制程序在CPU上的實際運行狀況（runtime），人們大多只能通過各種調(diào)試工具、窗口視圖等方式來間接地動態(tài)觀察這些真正的軟件的運行片段。因此，Java、C#、C++ 等等設(shè)計時（design time）源代碼在本質(zhì)上也是一種模型，雖然是一種經(jīng)處理后可執(zhí)行的靜態(tài)模型，但顯然它們并不是真實軟件和軟件架構(gòu)的全部。可見，源代碼模型（有時也叫實現(xiàn)模型）與UML模型其實都是軟件架構(gòu)的一種模型（邏輯反映），差別就在于抽象層次的不同。完整的軟件架構(gòu)（建筑）不僅僅包括源代碼（實現(xiàn)模型），還包括了需求模型、分析模型、設(shè)計模型、實現(xiàn)模型和測試模型等等許多模型，軟件架構(gòu)本身就是一組模型的集合。

    UML、SysML是當(dāng)前國際上流行的軟件/系統(tǒng)架構(gòu)可視化建模語言。在編寫實際的代碼之前，利用包圖、類圖、活動圖、交互圖、狀態(tài)圖等等各種標(biāo)準(zhǔn)圖形符號對軟件架構(gòu)進(jìn)行建模，探討和交流各種可行的設(shè)計方案，發(fā)現(xiàn)潛在的設(shè)計問題，保證具體編碼實現(xiàn)之前抽象設(shè)計的正確性，被實踐證明是一種非常有效和高效、敏捷的工作方式。

    架構(gòu)設(shè)計的重用

    重用（Reuse）是在軟件工程實踐中獲得高效率、高質(zhì)量產(chǎn)品和系統(tǒng)開發(fā)的一種基本手段和主要途徑，通過有組織的、系統(tǒng)和有效的重用，我們往往可以獲得10倍率以上的效率提升。而一個優(yōu)秀的、有長久生命力的軟件架構(gòu)（比方主流的一些框架軟件），其本身或其組件被重用的次數(shù)越多，其體現(xiàn)的價值也就越大。

    軟件重用有各種不同的范圍、層次、粒度和類型，從函數(shù)重用、類重用、構(gòu)件/組件重用、庫（API）重用，到框架重用、架構(gòu)重用、模式重用，再到軟件設(shè)計知識、思想的重用等等，重用的效能和效果各有不同。

    軟件工程經(jīng)過幾十年的發(fā)展，已經(jīng)積累了大量的軟件架構(gòu)模式和設(shè)計模式，它們記載、蘊(yùn)藏了大量成熟、已經(jīng)驗證的軟件設(shè)計知識、思想和經(jīng)驗。我們平時對各種基礎(chǔ)平臺、主流框架和API的應(yīng)用和調(diào)用，本身就是一種最為普遍的重用形式。而一個優(yōu)秀、成熟的軟件研發(fā)組織，必然會在日常開發(fā)中注意收集各種軟件設(shè)計知識和經(jīng)驗，建立和維護(hù)基于架構(gòu)模式和設(shè)計模式等內(nèi)容的軟件重用知識庫，積極主動和頻繁地運用各種軟件模式來解決實際工程問題。

    框架（Framework）是一類具有高可重用度的軟件，針對某一類應(yīng)用或領(lǐng)域，它們具有非常靈活的、高度可擴(kuò)展的軟件架構(gòu)。那么，如何才能設(shè)計出可重用的軟件架構(gòu)或其組件？借助于OOA、OOD等抽象分析和設(shè)計技術(shù)是一種重要的方法。人們在實踐中發(fā)現(xiàn)，往往越抽象的東西，其適應(yīng)面也就越廣，可重用度也就越高；相反，越具體的東西，其適應(yīng)面也就越窄，可重用度也就越低。重用，意味著充分利用現(xiàn)成、既有的東西、成果來解決新問題或重復(fù)的問題，以“不變”應(yīng)“萬變”。在軟件架構(gòu)設(shè)計中，應(yīng)該主動地區(qū)分軟件架構(gòu)中的“不變”與“可變”之處，系統(tǒng)地管理好這些穩(wěn)定點和變化點以適應(yīng)未來的變化，這也是提高軟件架構(gòu)重用度、獲得高質(zhì)量框架設(shè)計的一種重要方法。

    架構(gòu)設(shè)計的權(quán)衡

    與其它所有工程行業(yè)一樣，軟件工程本質(zhì)上也是一門講究權(quán)衡的科學(xué)和藝術(shù)。軟件架構(gòu)設(shè)計的最難之處往往在于如何在各種相互競爭、矛盾的制約條件之下，作出巧妙的最佳權(quán)衡。軟件架構(gòu)設(shè)計的權(quán)衡水平，也是最能體現(xiàn)軟件架構(gòu)師的設(shè)計經(jīng)驗、能力和技巧的地方。

    在軟件開發(fā)和軟件架構(gòu)的設(shè)計過程中，從選擇平臺，到選擇語言，選擇框架，選擇設(shè)計模式，選擇工具…等等，我們無時不刻都需要權(quán)衡，對各種候選項作出合理評判。在架構(gòu)師帶領(lǐng)下，軟件研發(fā)團(tuán)隊往往還需要對近期目標(biāo)與遠(yuǎn)期目標(biāo)、質(zhì)量與速度和效率、質(zhì)量與成本、功能與性能、靈活性與復(fù)雜性…等等許多彼此矛盾的設(shè)計選項、因素和約束進(jìn)行細(xì)致、小心和理性的權(quán)衡。

    理性權(quán)衡意味著科學(xué)決策。進(jìn)行有效的架構(gòu)設(shè)計權(quán)衡，離不開科學(xué)的方法，也就是如何運用定量分析和定性分析相結(jié)合的方法、因果邏輯和根源分析等等技術(shù)，找到最終的甜點（Sweet Spot）。許多時候，能否在很短的時間內(nèi)作出迅速、果斷而正確的科學(xué)權(quán)衡與取舍決策，構(gòu)成了一個軟件研發(fā)團(tuán)隊核心競爭能力的一部分。