軟體架構概念

 

前幾天，有幾個以前的同事到我家來玩，席間大家討論到目前流行的軟體架構。這些同事大部分目前轉向從事軟體架構工程師工作，有的想成長為軟體架構工程師。大家共同的感受是拋開具體項目談論軟體架構都覺得很簡單，不就是RUP的4+1視圖與軟體架構文檔麼。但針對具體的項目，總感到力不從心、無從下手，設計的軟體架構工作產品總得不到領導與同事的認可，不是有些問題領導與同事覺得沒有說清楚，就是有些東西領導與同事覺得過於羅索或繁鎖。大家請我根據多年從事軟體架構的經驗講講軟體架構究竟應該包含哪些內容、做到什麼程度。

而我本人向來注重學習某一理論知識的精神與指導思想並結合具體工作如何應用，不太注重太多的概念與理論，所以大家問到這個問題，我雖然知識大家對軟體架構的概念與思想認識存在一定的模糊，但我也一時無法向大家講解明白。而是我使用大家提到的一個項目為例，從多個方面指出大家的認識不足與正確做法，講了許多，最後看大家有點仿然大悟的表情下又隱約有許多滿腹疑惑，我只好說，我回頭好好整理一下思路，過幾天再與大家討論。

剛好這陣了有次我去中興網信面試，與一位資深的領導再次有幸談到軟體架構的話題。這位資深的領匯出了一道面試題，要我根據自己的經驗給軟體架構作個定義。我從記憶深處進行了深度搜尋，一來我向來注重學習某一理論知識的精神與指導思想並結合具體工作如何應用而不太注重太多的概念與理論，二來我記憶中所有的軟體架構學習書籍與資料中都迴避給軟體架構作一個統一的定義，大家都是從各自講解與重點關注的角度進行了闡述。於是我也從工作經驗將軟體架構從多個不同角度進行了我力能所及的說明與解釋，講了許多。最後這位資深的領導說我從思維發散的角度多視角的對軟體架構進行了較詳盡的闡述，但能不能從思維收斂的角度對軟體架構作一個精簡的定義。我搖搖頭，實在很難用精簡的語句說明的。而是這位資深的領導用一句話概括：軟體架構就是軟體系統的主要包括的元素及這些元素間的關係。

雖然我沒有接到中興網信的回複，可是，當我聽到這位領導的概括後，我當時真的想拍案叫絕——雖然我心裡還是隱隱覺得該定義還是遺漏了點什麼重要的東西。

而是我把所有學習軟體架構的書籍與資料重新學習了一遍，並上網搜尋相關知識。還是延用這位資深領導的定義並結合工作經驗與再次學習體會，我這樣定義軟體架構：軟體系統包含的主要元素、重要約束與關鍵決策，以及它們之間的關係並如何進行協作互動，以滿足軟體系統的不同涉眾需求。

首先說說主要元素。這裡說的元素不但包括介面、類、組件，還應有架構、子系統、獨立程式（如資料庫伺服器）、管道、訊息等。為什麼是主要元素而不是所有元素。一、從需求的角度使用者首先並主要關注核心業務需求的滿足，如果核心業務需求不能滿足，其它的一切都不必講。這就好比去買手機，如果這部手機不能正常通話，就是再美觀、有再多的協助工具功能，也不能成其為手機，也就不會有人購買。軟體架構作為與客戶等涉眾人員溝通的工具，不能重點關注如何滿足這些核心業務需求的要求，也就失去它存在的意義。如果能夠有效把握這些主要的核心業務需求，也就離軟體項目的成功不遠了。二、從軟體項目開發的現實來看，大多數軟體項目都面臨項目工期的壓力，軟體架構工程師必須在一定的時間內決定架構設計方案，否則沒有軟體架構所提供的對技術的足夠指導以及對分工協作的足夠限制，開發設計編碼團隊將面臨項目失敗的風險。所以軟體架構工程師沒有時間對所有元素進行深入分析。三、人的精力、能力是有限的，如果不能把主要精力和時間花在決定軟體項目成功的核心業務需求上，而是所有軟體需求與元素上，最終導致所有需求與元素都分析了又都不夠深入，這樣的軟體架構只能是流於形式的軟體架構，對提高軟體的品質不但沒有協助反而會害軟體項目失敗。

最容易被忽略的可能是重要約束。在說明重要約束的重要性前看看這樣一個例子：C/S軟體系統需要實現資訊量不大的高並發即時網路通訊，對於大多數有經驗的軟體架構工程師都會摒棄SELECT方式的無論是同步還是非同步、阻塞還是非阻塞SOCKET通訊模式，而會選擇IOCP。但如果軟體系統有一條運行約束：系統必須運行在LINUX下，整個軟體系統的架構都面臨巨大衝擊：LINUX下根本不支援IOCP。必須使用EPOLL。所以，許多約束之中其實隱藏著一些隱含的需求，它通過以下三種路徑影響軟體系統：一、直接制約設計決策。如上面的例子，架構工程師必須直接遵循，並影響關鍵決策。二、引申並轉化為功能需求。這種情況下可能會增加軟體系統的元素，如果在軟體架構中不進行必要的說明，軟體項目的涉眾人員可能會對這些"無緣無故突然冒出來的"元素表示疑惑。三、引申並轉化為非功能需求。這種情況下也可能會影響關鍵決策。

可以這樣講：軟體架構的每一個過程中的每一步工作都是一系列的重要設計決策。可是最難讓人理解是軟體架構如何包含決策。這裡有兩個誤解：一是認為軟體架構就是RUP的4+1視圖與軟體架構文檔，所以無法說明這些決策。二是在軟體架構中引入的每一個設計模式、架構，其實就表現了一系列決策。所以雖然人們不理解軟體架構如何包含決策，但其實每一位架構工程師都在不自覺的包含決策。我之所以提出是希望在架構過程中應主動有意識的包含這些關鍵決策。

主要元素、重要約束與關鍵決策從局部靜態孤立的說明了軟體系統的組成成份，而它們之間的關係則是說明它們是如何靜態組成一個有機的軟體系統整體的；如何進行協作互動則是從動態角度說明軟體系統是能進行怎樣的行為、怎樣滿足軟體系統的不同涉眾需求。

我之所以決定採用部落格的方式來進行軟體架構的學習，就是知識自己的認識還是有片面性的一面，希望將自己的學習體會寫出來，一來可以交流、共用、儲存；二來希望有不吝賜教的同會能有建設性的拍磚，協助我提高。