什麼是軟體架構

軟體架構的定義是很不嚴謹的，有很多不同的表述，有人還把這些表述分為所謂決策派和組成派什麼的。我不準備在這裡給讀者們引經據典。那是考據者的事，不是工作者的事。我表述我的觀點。同時我認為，如果你接受我的觀點，用這個觀點來重新看原來的那些觀點，就會發現他們表達的是同一個事情。

用什麼辦法可以「定義」一個軟體呢？把軟體Specification寫成什麼樣才能嚴格「定義」一個軟體呢？在我剛入行的時候，和身邊的同事有過很多關於這個問題討論，當時中國（也許全世界都一樣，但當時我的眼界不夠，也不知道是不是）的軟體水平如此之低。我們在這個問題上是很迷惘的。我們經常糾纏於類似這樣的問題： 「軟體設計文檔要寫到多細才叫設計好了？」，「軟體設計文檔是否要列出所有的函數？是否要指明這些函數所有的輸入輸出？」

現在看來，這個問題其實很簡單。什麼東西能夠嚴格定義一個軟體的行為？當然是源代碼啊。對於每個情形軟體的狀態機應該如何反應，不是只有軟體源代碼本身才能完整表述嗎？理解這一點，你就會發現，嚴格定義的盡頭，就是源代碼本身，包括編譯這個源代碼的腳本。最嚴謹的設計文檔，就是源代碼。

既然如此，如果我們要寫一個「完美」的設計文檔，就應該直接開始寫源代碼。實際上，現在很多人都是這樣的，我們常常都是直接寫源代碼的。

我有一個同學，他爸爸是美院的教授，他畫畫的時候，從來不定架子的，畫個頭，然後補眼睛，把眼睛全部畫好了，然後畫鼻子……他說他這種畫法，被他爸爸批為不走正道。但無論如何，他的畫是比我畫得好多了，我拿筆對著要畫的東西比半天比例，畫出來都沒有他畫的傳神。我舉這個例子，是要說，你如果罩得住，在不斷給代碼加細節的時候你就腦子裡永遠都知道你這個細節在整體上的位置是什麼，你根本不需要寫設計文檔，你寫出代碼來就好了。

所以，並沒有什麼必然的如何寫設計文檔的方法，關鍵是你的腦子有多清晰。像我，幾個電話號碼都記不利索的，你讓我不要進行設計推演，這是肯定不可能的。對端發過來一個請求，我創建一個會話，對端再發初始化信息，我進入準備態，然後超時，我切換到待機狀態……這樣的設計邏輯，你讓我從代碼中理出頭緒來，我肯定是做不到的，那我就需要畫STD（狀態變遷圖），推演所有可能的狀態變遷，化簡狀態和Action的數量。這個STD，就是我的「設計」，這種設計同樣可以表述在代碼中。是寫成文檔，還是直接變成代碼，取決於我（包括我的團隊）對這個問題的理解能力有多強，以及代碼在這個問題上需要綜合表述多少個邏輯。我曾經寫過一個驅動，狀態機管理本身就是一個子模塊，可以直接從數據結構上看到所有的狀態以及變遷條件和變遷引起的action，這種情況，代碼就可以是設計本身的。

所以，「設計應該做到多細」，這個問題是沒有答案的，設計是素描的時候你畫的所有輔助線，以及你先畫出來的部分，在這個設計過程中，你不斷增加細節，這些細節很大部分可能就是代碼，他們全部是設計的一部分。

理解了設計意味著什麼，你也就理解了構架設計意味著什麼。然後你就可以理解克萊門茨在《軟體架構編檔》中的那個總結了——「架構是架構師眼中的設計」。我們從構架進展到設計，然後進展到代碼。它們之間並沒有清晰的界限。構架也許一開始就是代碼，也許是狀態圖，也許是4+1視圖，並沒有固定的方法，這都取決於設計對象和設計本身。它們都是架構師對整個設計過程的預判。

所以，構架是一門無法從學院和教材學習的學問，要裝作自己在做架構設計很容易，要讓架構設計變成最後的代碼才是難點。就好像你叼根煙，皺著眉頭對著地圖的樣子也很像個元帥。但是不是元帥看的是你能否把仗打贏，不是看你叼煙的樣子是不是夠屌。

我們理解軟體構架的這個特點，知道我們能做什麼和不能做什麼，面對的困難是什麼，我們才有可能理解常用的構架工具，比如DFD/AFD，STD，Use Case這樣的工具，到底可以解決什麼問題，不能解決什麼問題。而直接學習這些工具，並不能讓你學會軟體構架。