架構整潔之道(一)——什麼是設計和架構

在過去幾年裏，關於設計和架構存在不少疑問。什麼是設計，什麼是架構，二者有什麼不一樣？
本書的其中一個目的就是消除全部的困惑，而且完全地給一個確切的定義，設計和架構是什麼.對於初學者來講這二者沒有區別，一點也沒有

架構這個詞常常被用在一些高級別的，與低級別的細節分離的上下文當中.而」設計「常常看起來暗示在低級別的決議和結構。可是當你看到架構師作的架構，這種說法又是荒謬的。

思考一下，假如架構師設計你的房子，這個房子有架構嗎？固然有。那它的架構又是什麼呢。是它的形狀，外貌，立體面圖，空間和房間的佈局。可是當我瀏覽架構師畫出的圖。我看到了大量的低級別的細節實現，我看見每個插座，電燈開關，電燈被標註出來。我看見哪些開關控制哪些電燈。我看到了放置火爐的位置，熱水器和抽水泵的大小和位置都被標註了出來，我看見了牆，屋頂，地基將如何被搭建

簡而言之，我看見所有的支持頂層決策的底層細節，也看見了底層細節和頂層決策是整個房屋設計的一部分.

因此這就是軟件設計，底層細節和頂層結構是相同物體的一部分.它們組成了一個連續的，能定義系統形狀的構造物。二者缺一不可。二者沒有明確的分割線，

軟件設計的目標

好的軟件設計的目標和我烏托邦式的描述如出一轍。軟件架構的目標是用最少的人力資源搭建和維護要求的系統。設計質量的權衡也就是知足用戶需求所付出的成本的權衡.若是成本很低，而且至始至終都很低。這就是一個優秀的設計。若是成本很高，並且每次發佈新版本，成本逐漸上升。這種設計就比較差。很簡單。

實例學習

舉個例子，思考下接下來的實例學習。它包含了來自匿名公司的真實數據，首先，讓咱們看看工程師的增加，我敢確定你你會以爲這個傾向很振奮人心。

讓咱們看看該公司同時期的產出，靠代碼條形圖來衡量

很明顯有些東西正在變糟，即便每一個版本都有在逐漸增長的工程師支持，但代碼的增加接近不對稱.
如今來看一張圖，這張圖展現了每行代碼的維護成本

這種傾向不是可持續發展的，無論此刻公司是多麼盈利。是什麼形成了這種明顯的變化，爲何代碼從第8版到第1版貴了40多倍

混亂的標誌

當多個系統被快速地發佈,當大量的程序員是惟一的動力輸出時，當不多甚至沒有在代碼清潔或者結構設計考慮,你看到的這些狀況都是混亂的標誌。
下面這條曲線看起來就像開發者，他們最初是100%的生產力，每發佈一個版本，他們的生產力就會降低.到第四版就逐漸接近0.

來自開發者的觀點：這很是讓人沮喪，由於每一個人都很是努力，沒有人減小付出。
至今,儘管開發者加班，奉獻，可是沒有取得任何實質性進展。他們所有的付出遠離需求，消費在處理混亂上。他們的工做變成了將混亂從一個地方移到另外一個地方，而後再移到一個地方。。。因此他們幾乎不多加功能。

什麼變遭了

大約2600年前,伊索寓言的龜兔賽跑，這個故事的寓意被用許多方式闡明：

1. 慢而穩贏得了比賽
2. 比的不是速度，而是強大
3. 欲速則不達

故事自己闡述了過度自信的愚蠢，兔子對自身速度太自信，以致於沒有認真應對比賽,而且在比賽途中睡覺。當烏龜衝過線後，兔子還在睡
如今的開發者就比如這場賽跑，展示出類似的自信,他們不睡覺，全靠一股子蠻勁，可是他們一部分大腦已經休息，管理乾淨，優秀的代碼的那部分
那些開發者都撒着一個熟悉的慌，我之後再清理，如今咱們必須先取得市場，固然，這些過後來都沒有作，由於市場的壓力歷來沒減小過.首先得到市場意味着你後面尾隨着一大羣競爭者，你必須靠盡本身最大努力來保持領先地位。
因此開發者不會轉變模式去修理和清潔垃圾，由於他們已經拿到了下一個要作的需求，需求老是不斷地來下一個。混亂不斷地製造，生產力繼續無限接近0.
兔子對速度過度自信，開發者對生產能力過度自信,可是代碼問題會慢慢地削弱生產力，毫不休息和緩和。若是任由發展，把生產力降到0大約只須要一個月
更大的謊話是寫髒代碼短時間讓程序員更快，只是長期會放慢。那些接受了該觀點的程序員相信他們從製造髒代碼模式到清理髒代碼模式的轉換能力，從而表現出了兔子的過度自信能力。可是他們也犯了一個巨大的錯誤。寫髒代碼比保持乾淨更耗時間，不管什麼樣的規模。

結論

在每個例子中，最好的選項是開發組織意識到他們的過度自信，而且開始嚴肅對待軟件架構的質量,爲了認真對待軟件架構，咱們須要知道什麼是好的軟件架構。爲了搭建一個用友最小消耗，最大生產力的設計和架構，咱們須要知道須要什麼因素。這就是這本書講的內容，好的架構和設計長什麼樣，以致於咱們有一個長期有利可圖的系統