中國科學技術大學軟件學院 ? 王松 ? 原創作品版權所有轉載請注明出處

? ? ? ? 本科時就聽說過《架構之美》這本書，但一直覺得會很深奧而沒敢去看。這次課外閱讀書籍中再次出現這本書，于是下定決心拜讀一下這本著作。

? ? ? ??敲了幾年代碼，總覺得代碼比較實際，架構比較空洞。“虛幻”的架構往往讓人摸不著頭腦，因為架構難以落在紙上，人們談起架構時又總是以一種只可意會不可言傳的姿態。美麗的架構無法定義，可它卻一定是自然的、簡單的、可復用的、人文的，甚至是外行人也可以細細品味其思想的。

? ? ? ??什么是架構？我們將“架構”作為一個名詞，它意味著一組工件，包括像藍圖和構建規范這樣的文檔。這些工件描述了要構建的對象。Jim Waldo和其他人曾指出，沒有什么過程可以保證你學了以后就能創造出好的架構，更不必說美的架構了，所以我們將更關注工件，而非過程。從這些能看出，雖然我們無法學習創造美的架構的步驟，但是我們可以通過學習判斷怎樣的架構是美的來幫助我們不斷發現架構中的缺陷。那些被我們所津津樂道的架構，都是大師們在日常工作里經歷了大量的錯誤、重復的嘗試、無數的代碼、長久的考驗所積淀下來的。如果我們也能找出架構中的不足不斷改進，總有一天會創造出美的架構。

? ? ? ??架構之美體現了關注點的分離與結合。在軟件設計中，設計師需要考慮多方面的關注點。漂亮的設計讓這些關注點盡可能分離，然后以最簡單的機制結合在一起，從而得到高內聚、低耦合的系統。而這些關注點往往都包含以下幾點：

功能性

???????? 產品向它的用戶提供哪些功能？

可變性

? ? ? ??軟件將來可能需要哪些改變？哪些改變不太可能發生，不需要特別容易進行這些改變？

性能

? ? ? ??產品將達到怎樣的性能？

容量

? ? ? ??多少用戶將并發使用該系統？該系統將為用戶保存多少數據？

生態系統

? ? ? ??在部署的生態環境中，該系統將與其他系統進行哪些交互？

模塊化

? ? ? ??如何將編寫軟件的任務分解為工作指派（模塊），特別是這些模塊可以獨立地開發，并能夠準確而容易地滿足彼此的需要？

可構建性

? ? ? ??如何將軟件構建為一組組件，并能夠獨立實現和驗證這些組件？哪些組件應該復用其他的產品，哪些應該從外部供應商處獲得？

產品化

? ? ? ??如果產品將以幾種變體的形式存在，如何開發一個產品線，并利用這些變體的共性？產品線中的產品以怎樣的步驟開發？在創建一條軟件產品線時，要進行哪些投資？開發產品線中不同變體的選擇，預期會得到怎樣的回報？特別是，是否可能先開發最小的有用產品，然后再添加（擴展）組件，在不改變以前編寫的代碼的情況下，開發產品線的其他成員？

安全性

? ? ? ??產品是否需要用戶認證，或者必須限制對數據的訪問？數據的安全性如何得到保證？如何抵擋“拒絕服務”攻擊或其他攻擊？

? ? ? ??好的架構必須滿足系統的利益相關人的功能和質量關注點。那么超過足夠好的架構是怎樣的呢？我們要從這些好的結構中進一步篩選，就要設立更高的門檻。首先，我們應該關注架構的實用性，它必須每天都被許多人使用。但是，在使用它之前它應該先構建，所以我們應該關注該架構的可構建性。接下來，我們想尋找那些展示了持久性的架構，也就是說，那些經過了時間考驗的架構。最后，我們還想尋找這樣一些架構，它們的特征讓使用、構建、測試這些架構的開發人員和測試人員，以及由它而形成的系統的用戶感到由衷的高興。

? ? ? ??作者通過“混亂大都市”和“設計之城”兩個例子向我們展示了架構如何對軟件項目產生深遠的影響。架構幾乎會影響所有與之相關的人和事。從這兩個例子，我們可以看出好的架構是很多因素的結果，包括以下方面（但不限于此）：

• 確實進行有意為之的前端設計。（許多項目甚至還沒開始，就因為這一點而失敗了。）
• 設計者的素質和經驗。（以前犯過一些錯誤是有幫助的，這能在下一次為你指出正確方向！）
• 在開發過程中，保持清晰的設計觀點。
• 授權團隊負責軟件的整體設計，而團隊也承擔起這一責任。
• 不要害怕改變設計：沒有什么是一成不變的。
• 讓合適的人加入到團隊中，包括設計者、程序員和經理，確保開發團隊的規模合適。確保他們具有健康的工作關系，因為這些關系將不可避免地影響代碼的結構。
• 在合適的時候做出設計決定，當你知道所有必要信息時再做出決定。延遲那些暫時不能做出的決定。
• 好的項目管理，以及合適的最后期限。

? ? ? ??最后作者通過企業級應用架構、系統架構、最終用戶應用架構以及語言與架構這些方面舉例說明了經典架構的美麗之處。

? ? ? ??我們總是認為不良的架構只是會影響到軟件的代碼，但是讀完這本書后，我發現，不良的架構的影響不僅限于代碼，它會進一步影響到人、團隊、過程和時間表。開發團隊的成員，尤其是新成員會被系統的復雜性驚嚇到，項目會給他們帶來巨大的壓力，尤其是規劃新的功能會導致極大的恐懼。由于系統的復雜性，所以即使是最簡單的變更都需要花費大量的實踐，從而導致管理項目的開發周期顯得極其困難。

? ? ? ??記得之前和宿舍的人一起討論工程實踐的概要設計時，他問了我幾個架構設計的問題，但當我問到他們的需求是什么時，他卻沒法給我明確的答復。我無法想象他們在沒有抓準需求的情況下做出的概要設計會是什么樣的。正如此書中所講的，“重要的是要在開始設計系統之前知道你打算設計什么。如果你不知道它是什么，也不知道它將做什么，暫時不要開始設計它。只設計你知道需求的東西。”

? ? ? ??“混亂大都市”之所以混亂的一個重要原因：在項目開始之初，團隊并不知道要構建的是什么。在規劃“大都市”的早期階段，有太多的架構師。面對糊涂的需求，他們都拿著一塊拼不起來的拼圖，試圖獨自工作。他們在工作時沒有考慮到整個項目，所以當他們試圖將這些拼圖拼在一起時，就拼不起來了。沒有時間進一步思考架構，軟件設計的各個部分有一些重疊，于是開始了“大都市”的城市規劃災難。

? ? ? ??很多同學不理解工程實踐開題時為什么要做那么細致的需求調研，還要對系統做出整體的概要設計。看完這本書，我開始明白這么做的意圖。如果我們在需求不清，整體設計不明的情況下就開始了項目的開發，最后我們的軟件肯定會成為另一個“混亂大都市”，甚至僅僅只能稱作“凌亂小房間”。

? ? ? ??對于我們平時遇到的這些小項目而言，我們需要決定的關注點可能沒有那些架構名人堂中的經典之作那么多。但我們同樣應該在項目的早期就決定一些基本的關注點，它能確保代碼能夠容易而一致地增長，這些決定包括：頂層文件結構，我們如何對事物命名，“內部”展示的風格，共用的編碼慣例，選擇單元測試框架，支持基礎設施（例如版本控制、適合的構建系統的持續集成）。

? ? ? ??當作出了設計決定后，就要進行品質控制過程。常見的品質控制手段包括：結對編程，對沒有結對編程的工作進行代碼/設計復審，對每一段代碼進行單元測試。一提到測試，估計很多程序員就開始煩惱了。大部分都很討厭測試環節，但是測試卻又非常重要。一組好的自動化測試可以讓我們在進行架構變更時風險最小。編寫單元測試確保了每個代碼模塊的內聚性，也確保了與系統其他部分之間的松耦合。單元測試迫使我們仔細考慮每個單元的接口，確保該單元的API是有意義的，內部是一致的。

? ? ? ??讀完整本書后感覺架構不再是那么神秘了，而是與每一位程序員都息息相關的，只要不斷從所經歷的項目的架構中吸取經驗，我們也能成為架構大師。在讀這本書期間，我擔任著工程實踐項目的組長，架構的設計也是我的任務之一。利用書中所學，我也開始一步步規劃起屬于我的“設計之城”。紙上得來終覺淺，只有在實踐中慢慢摸索，才能體會到架構的美麗之處。

總結

以上是生活随笔為你收集整理的初探架构之美的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。