什麼是軟體架構？

    什麼是軟體架構呢?

    去年畢業前期，大小的企業輪流來到學校進行宣講，對所謂的軟體開發的職業規劃做出了五花八門的說明，每個公司都有自己的特色，但總體來講，還是分為技術和管理兩條線，我不太喜歡做管理，所以只關注技術的發展路線，大部分都是這樣的：初級程式員——>中級程式員——>進階程式員——>架構師——>技術總監，我還算髮展的比較順利的，現在混到進階程式員的邊緣了，本著“不想當將軍計程車兵不是好士兵”的原則，我應該對架構師這個目前還是有些神秘的東東做一個比較深入的瞭解，這不，正愁沒有具體的實踐來和抽象的理論交相輝映的時候，公司如及時雨般把一個100+人月的項目分給我了，讓我擔當技術經理的角色，。

    當你去瞭解一個東東的時候，第一步要做的，就應該去知道這個東東的定義，對於軟體架構也是如此，經過網上查詢和書籍的協助，我大概理清了一個輪廓。

    軟體行業是一個熱衷於製造‘名詞’的行業，如果退回15年，估計沒幾個人知道‘軟體架構’是什麼，在上個世紀80年代，隨著軟體開發的規模不斷擴大，軟體開發成為一個行業，初期，隨之而來的是越來越多的軟體項目的失敗，造成項目失敗的原因很多，但主要集中在開發過程，所以軟體工程應運而生，CMMI等流程標準也是一茬接著一茬的冒個不停。

    在軟體工程初具規模的時候，軟體開發還是以資料結構+演算法的形式存在，進入20世紀最後10年，隨著物件導向技術、設計模式等在開發過程中的成功應用，軟體架構也走進了大家的視野。

    軟體架構在定義上分為‘組成派’和‘決策派’兩大陣營，分別描述如下：

    ’組成派‘認為軟體架構是將系統描述成計算群組件及組件之間的互動。它有兩個非常明顯的特點：

• 關注架構實踐的客體——軟體，以軟體本身作為描述對象。
• 分析了軟體的組成，說明軟體不是一個‘原子’意義上的整體，而是有不同的部分經過特定的介面進行串連組成的一個整體，這對軟體開發來說很重要。

    ‘決策派’認為軟體架構包含了一系列的決策，主要包括：

• 軟體系統的組織
• 選擇組成系統的結構元素和它們之間的介面，以及當這些元素相互協作時所體現的行為
• 如何組合這些元素，使它們逐漸合成為更大的子系統
• 用於指導這個系統組織的架構風格：這些元素以及它們的介面、協作和組合

    軟體架構並不僅僅關注軟體本身的結構和行為，還注重其他特性：使用、功能性、效能、彈性、重用、可理解、經濟以及技術的限制和權衡等。

    ‘決策派’有以下兩個顯著的特點：

• 關注軟體架構中的實體——人，以人的決策為描述對象。
• 歸納了軟體架構決策的類型，指出架構決策不僅包括關於軟體系統的組織、元素、子系統和架構風格等幾類決策，還包括關於眾多非功能性需求的決策。

    按照‘組成派’的觀點，軟體架構關注的是軟體整體的分割和互動，之所以分割，是因為不同的部分在邏輯或物理上相對獨立，通過‘分而治之’的原則進行分割可以更好的理解整個系統，把握使用者的需求，但是雖然整個軟體可以分割成多個模組或子系統，但是模組和子系統之間的通訊和互動也是很重要的，我想按照這種觀點，架構師的主要任務是將軟體分割成不同的模組，並定義模組之間的介面。

    按照‘決策派’的觀點，軟體是一個在很多限制下產生的產品，這些限制包括使用者和技術兩方面，使用者方麵包括功能需求、效能需求、硬體需求等，技術方麵包括技術選擇、可擴充性、可重用性、可維護性等。我想按照這中觀點，架構師的主要任務就是作出上述個各種限制作出選擇或決策。

    至於‘組成派’和‘決策派’之間是否是互斥的，我不認為這樣，實際上，很多牛人都不認為是這樣（呵呵，我也沾些牛人的牛氣），這兩種觀點應該是站在不同的角度來看待軟體架構，架構師在分割模組時，也會不得不去作出各種決策。

參考文獻：
《軟體架構設計》   溫昱