如何更好地進行軟件架構設計這是軟件工程領域中一個永恆的重點話題過去幾十年來國際軟件工程界在軟件架構設計方面已經獲得了長足發展大量圖書文章和文獻記載了這方面的成熟經驗與成果軟件架構設計往往是一件非常復雜的工作涉及到很多細節和方方面面可探討的話題也非常之多囿於篇幅限制以下只能根據筆者個人理解遴選出軟件架構設計的個別要點結合當前流行的敏捷軟件工程思想與大家分享一下自己在軟件架構設計方面的心得和體會
架構決定成敗
軟件架構是軟件產品軟件系統設計當中的主體結構和主要矛盾任何軟件都有架構哪怕一段短小的HelloWorld程序軟件架構設計的成敗決定了軟件產品和系統研發的成敗軟件架構自身所具有的屬性和特點決定了軟件架構設計的復雜性和難度
這幾年流行一個說法（管理諺語）細節決定成敗這句話其實只說對了一半細節確實很重要很多項目產品就輸在細節的執行上一方面戰術細節固然很重要但另一方面戰略全局也同樣重要對應的我們可以說戰略決定成敗戰略性失敗就好比下一盤圍棋局部下得再漂亮再凌厲如果罔顧大盤己方連空都不夠了還有官子（細節）獲勝的機會嗎？必然是中盤告負
類似地正確的軟件架構設計應該既包括戰略全局上的設計也包括戰術細節（關鍵路徑）上的設計有一種錯誤的觀點認為軟件架構設計只要分分層和包畫一個大體的輪廓草圖就完事了這種紙上談兵型的架構師行為是非常有害的事實上既然軟件架構是軟件建築的主體結構隱蔽工程承重牆和要害部位那麼軟件架構也必然要落實到實際的算法和代碼不但要有實現代碼還要包括對這部分架構進行測試的代碼以保證獲得高質量的滿足各種功能和非功能質量屬性要求的架構除了完成概念模型設計外軟件架構師一定要參與實際的編碼測試和調試做一位真正的handson practitioner這已經成為了敏捷軟件工程所倡導的主流文化
兩個架構
我們在日常的軟件產品和系統開發中實際上會遇到兩種兩個部分的軟件架構即待開發的應用部分的軟件架構（簡稱應用架構）以及既有的基礎平台部分的軟件架構（簡稱基礎架構）這兩部分架構之間是互為依賴相輔相成的關系它們共同組成了整個軟件產品和系統的架構
基礎架構的例子包括NET和JEE等主流的基礎平台和各種公共應用框架由基礎庫API對象模型事件模型各種開發和應用的擴展規則等內容組成我們只有熟悉基礎架構的構造細節應用機理才能有效地開發出高質量高性能的上層應用然而開發一個面向最終用戶的軟件應用系統和產品僅僅掌握一般的計算機高級編程語言知識和基礎平台架構API的使用知識顯然是不夠的我們還需要根據客戶應用的類型和特點在基礎架構之上設計出符合用戶要求的高質量應用軟件
熟悉OOAOOD抽象建模技術設計原則以及架構模式和設計模式等等方法技術不但有助於我們更好地理解和利用基礎平台架構也有助於我們設計開發出更高質量的應用軟件架構
風險驅動敏捷迭代的架構設計與開發
軟件架構將隨著軟件產品和系統的生命周期而演化其生命期往往超過了一個項目一次發布甚至有可能長達數年之久因而軟件架構無論對於客戶還是開發商來說都是一項極其重要的資產
軟件架構的設計應該遵循什麼樣的開發過程？或者說有沒有更好的成熟的軟件架構設計和開發過程？回答是世紀的軟件架構設計應該優先采用敏捷迭代的開發方式和方法與傳統做法不同敏捷迭代開發主張軟件架構采用演進式設計（evolutionary design）一個軟件產品或系統的架構是通過多次迭代乃至多次發布在開發生命周期中逐步建立和完善起來的
好的軟件架構不是一蹴而就的在架構設計開發過程中我們應該盡量避免瀑布式思維通過一個架構設計階段來完成系統的架構設計乃至詳細設計然後再根據架構圖紙和模型在編碼實現階段按圖索骥進行架構的編碼與實現這種傳統做法的錯誤在於認為軟件架構就是圖紙上的模型而不是真正可以高質量執行的源代碼幾十年的軟件工程實踐表明沒有經過代碼實現測試用戶確認過的架構設計往往會存在著不可靠的臆想猜測和過度設計過度工程極易造成浪費和返工導致較高的失敗率
風險是任何可能阻礙和導致軟件產品/系統研發失敗的潛在因素和問題軟件架構是軟件產品和系統研發的主要矛盾和主要技術風險軟件架構的質量決定了整個軟件系統和產品的質量不確定性往往是軟件架構設計當中一種最大的潛在風險因此軟件架構的設計與開發應該遵循風險驅動的原則在整個開發生命周期內至始至終維護一張風險問題清單隨著迭代的前進根據風險的實時動態變化首先化解和處理最主要的架構風險再依次化解和處理次要的架構風險
架構設計的可視化建模
軟件架構設計的難度源於軟件設計問題本身的復雜性一個復雜的軟件系統往往存在大量復雜的難於被人類所理解的細節和不確定因素抽象與建模是人類自誕生以來就已掌握的理解復雜事物的方法因而人類所從事的軟件設計工作本質上也是一個不斷建模的過程我們可以通過各種抽象的模型和視圖從各個不同層次宏觀和微觀的角度來理解復雜的軟件架構以保證作出正確和有效的設計
有人認為軟件架構就是源代碼（source codes）以及源代碼就是設計這種說法其實是片面的什麼是真正的軟件？我們知道最終可以在電腦上執行的真正的軟件其實是二進制代碼和借助編譯器我們把高級編程語言翻譯成底層的匯編語言機器語言等沒有人能直接完整地看到二進制程序在CPU上的實際運行狀況（runtime）人們大多只能通過各種調試工具窗口視圖等方式來間接地動態觀察這些真正的軟件的運行片段因此JavaC#C++ 等等設計時（design time）源代碼在本質上也是一種模型雖然是一種經處理後可執行的靜態模型但顯然它們並不是真實軟件和軟件架構的全部可見源代碼模型（有時也叫實現模型）與UML模型其實都是軟件架構的一種模型（邏輯反映）差別就在於抽象層次的不同完整的軟件架構（建築）不僅僅包括源代碼（實現模型）還包括了需求模型分析模型設計模型實現模型和測試模型等等許多模型軟件架構本身就是一組模型的集合
UMLSysML是當前國際上流行的軟件/系統架構可視化建模語言在編寫實際的代碼之前利用包圖類圖活動圖交互圖狀態圖等等各種標准圖形符號對軟件架構進行建模探討和交流各種可行的設計方案發現潛在的設計問題保證具體編碼實現之前抽象設計的正確性被實踐證明是一種非常有效和高效敏捷的工作方式
架構設計的重用
重用（Reuse）是在軟件工程實踐中獲得高效率高質量產品和系統開發的一種基本手段和主要途徑通過有組織的系統和有效的重用我們往往可以獲得倍率以上的效率提升而一個優秀的有長久生命力的軟件架構（比方主流的一些框架軟件）其本身或其組件被重用的次數越多其體現的價值也就越大
軟件重用有各種不同的范圍層次粒度和類型從函數重用類重用構件/組件重用庫（API）重用到框架重用架構重用模式重用再到軟件設計知識思想的重用等等重用的效能和效果各有不同
軟件工程經過幾十年的發展已經積累了大量的軟件架構模式和設計模式它們記載蘊藏了大量成熟已經驗證的軟件設計知識思想和經驗我們平時對各種基礎平台主流框架和API的應用和調用本身就是一種最為普遍的重用形式而一個優秀成熟的軟件研發組織必然會在日常開發中注意收集各種軟件設計知識和經驗建立和維護基於架構模式和設計模式等內容的軟件重用知識庫積極主動和頻繁地運用各種軟件模式來解決實際工程問題
框架（Framework）是一類具有高可重用度的軟件針對某一類應用或領域它們具有非常靈活的高度可擴展的軟件架構那麼如何才能設計出可重用的軟件架構或其組件？借助於OOAOOD等抽象分析和設計技術是一種重要的方法人們在實踐中發現往往越抽象的東西其適應面也就越廣可重用度也就越高相反越具體的東西其適應面也就越窄可重用度也就越低重用意味著充分利用現成既有的東西成果來解決新問題或重復的問題以不變應萬變在軟件架構設計中應該主動地區分軟件架構中的不變與可變之處系統地管理好這些穩定點和變化點以適應未來的變化這也是提高軟件架構重用度獲得高質量框架設計的一種重要方法
架構設計的權衡
與其它所有工程行業一樣軟件工程本質上也是一門講究權衡的科學和藝術軟件架構設計的最難之處往往在於如何在各種相互競爭矛盾的制約條件之下作出巧妙的最佳權衡軟件架構設計的權衡水平也是最能體現軟件架構師的設計經驗能力和技巧的地方
在軟件開發和軟件架構的設計過程中從選擇平台到選擇語言選擇框架選擇設計模式選擇工具…等等我們無時不刻都需要權衡對各種候選項作出合理評判在架構師帶領下軟件研發團隊往往還需要對近期目標與遠期目標質量與速度和效率質量與成本功能與性能靈活性與復雜性…等等許多彼此矛盾的設計選項因素和約束進行細致小心和理性的權衡
理性權衡意味著科學決策進行有效的架構設計權衡離不開科學的方法也就是如何運用定量分析和定性分析相結合的方法因果邏輯和根源分析等等技術找到最終的甜點（Sweet Spot）許多時候能否在很短的時間內作出迅速果斷而正確的科學權衡與取捨決策構成了一個軟件研發團隊核心競爭能力的一部分
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27294.html
