軟體架構設計漫談

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

架構決定成敗

軟體架構是軟體產品、軟體系統設計當中的主體結構和主要矛盾。任何軟體都有架構，哪怕一段短小的HelloWorld程式。軟體架構設計的成敗決定了軟體產品和系統研發的成敗。軟體架構自身所具有的屬性和特點，決定了軟體架構設計的複雜性和難度。

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

類似地，正確的軟體架構設計，應該既包括戰略全域上的設計，也包括戰術細節（關鍵路徑）上的設計。有一種錯誤的觀點認為，軟體架構設計只要分分層和包，畫一個大體的輪廓草圖，就完事了。這種“紙上談兵”型的架構師行為是非常有害的。事實上，既然軟體架構是軟體建築的主體結構、隱蔽工程、承重牆和要害部位，那麼軟體架構也必然要落實到實際的演算法和代碼，不但要有實現代碼，還要包括對這部分架構進行測試的代碼，以保證獲得高品質的、滿足各種功能和非功能品質屬性要求的架構。除了完成概念、模型設計外，軟體架構師一定要參與實際的編碼、測試和調試，做一位真正的hands-on practitioner，這已經成為了敏捷軟體工程所倡導的主流文化。

兩個架構

我們在日常的軟體產品和系統開發中，實際上會遇到兩種、兩個部分的軟體架構，即待開發的應用部分的軟體架構（簡稱“應用架構”），以及既有的基礎平台部分的軟體架構（簡稱“基礎架構”）。這兩部分架構之間是互為依賴、相輔相成的關係，它們共同組成了整個軟體產品和系統的架構。

基礎架構的例子包括：.NET和J2EE等主流的基礎平台和各種公用應用程式框架，由基礎庫API、物件模型、事件模型、各種開發和應用的擴充規則等內容組成。我們只有熟悉基礎架構的構造細節、應用機理，才能有效地開發出高品質、高效能的上層應用。然而，開發一個面向終端使用者的軟體應用系統和產品，僅僅掌握一般的電腦進階程式設計語言知識和基礎平台架構、API的使用知識顯然是不夠的，我們還需要根據客戶應用的類型和特點，在基礎架構之上，設計出符合使用者要求的高品質應用軟體。

熟悉OOA、OOD抽象建模技術、設計原則以及架構模式和設計模式等等方法技術，不但有助於我們更好地理解和利用基礎平台架構，也有助於我們設計開發出更高品質的應用軟體架構。

風險驅動、敏捷迭代的架構設計與開發

軟體架構將隨著軟體產品和系統的生命週期而演化，其生命期往往超過了一個項目、一次發布，甚至有可能長達數年之久，因而軟體架構無論對於客戶還是開發商來說都是一項極其重要的資產。

軟體架構的設計應該遵循什麼樣的開發過程？或者說，有沒有更好的、成熟的軟體架構設計和開發過程？回答是，21世紀的軟體架構設計應該優先採用敏捷迭代的開發方式和方法。與傳統做法不同，敏捷反覆式開發法主張軟體架構採用演化式設計（evolutionary design），一個軟體產品或系統的架構是通過多次迭代，乃至多次發布，在開發生命週期中逐步建立和完善起來的。

好的軟體架構不是一蹴而就的。在架構設計開發過程中，我們應該盡量避免瀑布式思維，通過一個“架構設計階段”來完成系統的架構設計乃至詳細設計，然後再根據架構圖紙和模型，在“編碼實現階段”按圖索驥進行架構的編碼與實現。這種傳統做法的錯誤在於認為軟體架構就是圖紙上的模型，而不是真正可以高品質執行的原始碼。幾十年的軟體工程實踐表明，沒有經過代碼實現、測試、使用者確認過的架構設計，往往會存在著不可靠的臆想、猜測和過度設計、過度工程，極易造成浪費和返工，導致較高的失敗率。

風險是任何可能阻礙和導致軟體產品/系統研發失敗的潛在因素和問題。軟體架構是軟體產品和系統研發的主要矛盾和主要技術風險，軟體架構的品質決定了整個軟體系統和產品的品質。不確定性往往是軟體架構設計當中一種最大的潛在風險。因此，軟體架構的設計與開發應該遵循風險驅動的原則，在整個開發生命週期內至始至終維護一張風險問題清單，隨著迭代的前進，根據風險的即時動態變化，首先化解和處理最主要的架構風險，再依次化解和處理次要的架構風險。
架構設計的可視化建模

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

有人認為：“軟體架構就是原始碼（source codes）”以及“原始碼就是設計”。這種說法其實是片面的。什麼是真正的軟體？我們知道，最終可以在電腦上執行的真正的軟體其實是二進位代碼0和1，藉助編譯器我們把進階程式設計語言翻譯成底層的組合語言、機器語言等，沒有人能直接、完整地看到二進位程式在CPU上的實際健全狀態（runtime），人們大多隻能通過各種調試工具、視窗視圖等方式來間接地動態觀察這些真正的軟體的運行片段。因此，Java、C#、C++ 等等設計時（design time）原始碼在本質上也是一種模型，雖然是一種經處理後可執行檔靜態模型，但顯然它們並不是真實軟體和軟體架構的全部。可見，原始碼模型（有時也叫實現模型）與UML模型其實都是軟體架構的一種模型（邏輯反映），差別就在於抽象層次的不同。完整的軟體架構（建築）不僅僅包括原始碼（實現模型），還包括了需求模型、分析模型、設計模型、實現模型和測試模型等等許多模型，軟體架構本身就是一組模型的集合。

UML、SysML是當前國際上流行的軟體/系統架構可視化建模語言。在編寫實際的代碼之前，利用包圖、類圖、活動圖表、互動圖、狀態圖等等各種標準圖形符號對軟體架構進行建模，探討和交流各種可行的設計方案，發現潛在的設計問題，保證具體編碼實現之前抽象設計的正確性，被實踐證明是一種非常有效和高效、敏捷的工作方式。

架構設計的重用

重用（Reuse）是在軟體工程實踐中獲得高效率、高品質產品和系統開發的一種基本手段和主要途徑，通過有組織的、系統和有效重用，我們往往可以獲得10倍率以上的效率提升。而一個優秀的、有長久生命力的軟體架構（比方主流的一些架構軟體），其本身或其組件被重用的次數越多，其體現的價值也就越大。 軟體重用有各種不同的範圍、層次、粒度和類型，從函數重用、類重用、構件/組件重用、庫（API）重用，到架構重用、架構重用、模式重用，再到軟體設計知識、思想的重用等等，重用的效能和效果各有不同。

軟體工程經過幾十年的發展，已經積累了大量的軟體架構模式和設計模式，它們記載、蘊藏了大量成熟、已經驗證的軟體設計知識、思想和經驗。我們平時對各種基礎平台、主流架構和API的應用和調用，本身就是一種最為普遍的重用形式。而一個優秀、成熟的軟體研發組織，必然會在日常開發中注意收集各種軟體設計知識和經驗，建立和維護基於架構模式和設計模式等內容的軟體重用知識庫，積極主動和頻繁地運用各種軟體模式來解決實際工程問題。

架構（Framework）是一類具有高可重用度的軟體，針對某一類應用或領域，它們具有非常靈活的、高度可擴充的軟體架構。那麼，如何才能設計出可重用的軟體架構或其組件？藉助於OOA、OOD等抽象分析和設計技術是一種重要的方法。人們在實踐中發現，往往越抽象的東西，其適應面也就越廣，可重用度也就越高；相反，越具體的東西，其適應面也就越窄，可重用度也就越低。重用，意味著充分利用現成、既有的東西、成果來解決新問題或重複的問題，以“不變”應“萬變”。在軟體架構設計中，應該主動地區分軟體架構中的“不變”與“可變”之處，系統地管理好這些穩定點和變化點以適應未來的變化，這也是提高軟體架構重用度、獲得高品質架構設計的一種重要方法。

架構設計的權衡

與其它所有工程行業一樣，軟體工程本質上也是一門講究權衡的科學和藝術。軟體架構設計的最難之處往往在於如何在各種相互競爭、矛盾的制約條件之下，作出巧妙的最佳權衡。軟體架構設計的權衡水平，也是最能體現軟體架構師的設計經驗、能力和技巧的地方。

在軟體開發和軟體架構的設計過程中，從選擇平台，到選擇語言，選擇架構，選擇設計模式，選擇工具…等等，我們無時不刻都需要權衡，對各種候選項作出合理評判。在架構師帶領下，軟體研發團隊往往還需要對近期目標與遠期目標、品質與速度和效率、品質與成本、功能與效能、靈活性與複雜性…等等許多彼此矛盾的設計選項、因素和約束進行細緻、小心和理性的權衡。

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