Beautiful Architecture

Leading Thinkers Reveal the Hidden Beauty in Software Design

By

Diomidis Spinellis , Georgios Gousios

http://oreilly.com/catalog/9780596517984

架構是系統設計的一部分，它突出了某些細節，并通過抽象省略掉了另一些細節。軟件系統的架構包括行為上的和結構上的。外部行為描述展示了軟件如何與用戶、其他設備和外部設備進行交互，也就是需求。結構描述展示了軟件如何被劃分為多個部分，以及這些部分的關系。

架構的設計受到許多因素的制約，架構是好是壞并沒有統一的標準。這取決于人們對軟件的需求、軟件被構建和運行的環境，以及軟件團隊本身的特點等等因素。評價軟件好壞有很多指標，例如性能、安全、可伸展性等等。一般來說，這些指標是很難全部滿足的，試圖改進其中一個往往會對其他指標產生負面影響。所以從某種意義上來說，軟件架構是折中的游戲。對于一組功能需求和品質需求，沒有唯一的正確架構。

《架構之美》沒有太多空洞的概念和論述，而是拋磚引玉地展示多個實際的項目。通過對它們架構利弊的分析，以及相關的思考，給讀者提供了有益的啟發。在這里我簡單介紹幾個其中的例子。

“混亂大都市”和“設計之城”

一個例子是兩個類似但是命運完全不同的項目：“混亂大都市”和“設計之城”。

“混亂大都市”來自于一家成立不久的公司。軟件的延期是不可容忍的，所以軟件工程師們被迫盡其極限快速交付。代碼是以一系列的瘋狂沖刺方式堆疊在一起的，這使得“混亂大都市”從一開始就缺乏規劃，導致了一系列惡果。結構混亂難以理解，沒有清晰的層次，模塊間的依賴關系錯綜復雜；組件的角色定義模糊，本該在這個組件的事情卻在另一個組件里實現；整個項目完全是由膠帶、Shell腳本、Perl膠水、makefile和Visual Studio項目混合在一起的。

新手難以快速熟悉這個項目，就連老手也不知道整個項目的全景。所有人花費了大量精力得到了一份“架構圖”，看上去像倫敦地鐵圖，甚至還有環線：

?

最終這家公司放棄了“混亂大都市”項目，并組織團隊重新編寫，祝他們好運……

“設計之城”與“混亂大都市”類似，都是C++編寫的音頻軟件。從一開始，項目就有了清晰的目標：具體的首個產品和未來功能的路線圖，代碼必須支持這些功能和未來的變化。

團隊采用了極限編程的方法，對于項目的很多關注點作了規定。例如統一的文件結構、命名規范、編碼慣例等等。并且在系統核心的設計上花費的不少時間，最終得到了一個“過濾器和管道”的架構：

?

此書編寫時“設計之城”仍然在使用中，并且擴展出了一些成功的產品。事實上，“設計之城”的代碼并不完美，有些地方存在技術爭論，但是在整潔的背景下這些問題顯得特別突出，從而在將來會得到解決。

GNU Emacs

另一個例子是GNU Emacs

Emacs是當今流行的文本編輯器之一。Emacs于上世紀70年代中旬開始開發，至今已走過了三十多年，但其架構基本沒有改變過。而且，Emacs的特性在不斷地增加中。

Emacs采用了交互式應用程序中應用廣泛的“模型-視圖-控制器”模式。模型是程序所操作數據的底層描述；視圖時向用戶展示數據的方法；控制器負責實現用戶與視圖的交互，并對模型進行更新。

?

• Emacs的模型，緩沖區就是簡單的字符串。每個緩沖區都有一種模式，用來指定對特定類型文本進行編輯時的行為；緩沖區還維護了一個撤銷日志，用來記住各個用戶命令間的邊界；此外緩沖區還為文本在緩沖區中的定位提供的支持；緩沖區中的每個字符有自己的屬性，包括如何顯示以及如何應對鼠標操作等。
• Emacs的視圖可以自動更新顯示結果，并且只在用戶輸入時更新。例如現在的網頁瀏覽器就借鑒了這樣的方式。
• Emacs的控制器是用自己獨立的Emacs Lisp語言開發的。Emacs幾乎所有的功能都由Emacs Lisp實現，用戶可以自己編寫Emacs Lisp程序來擴充Emacs的功能。事實上，通常的Emacs發行版就包含了很多流行的Emacs Lisp包。

隨著軟件的特性不斷增長，用戶界面將變得復雜，程序本身將變得難以維護。評價一個程序的用戶界面復雜度，有兩個常見的維度：要維護的模型的復雜度，以及操作該模型命令集的復雜度。

Emacs的模型，即緩沖區僅僅是字符串，緩沖區的改變永遠是可見的；Emacs的命令非常之多，但是一個新用戶完全可以像使用其他基本的文本編輯器一樣使用Emacs，Emacs還提供了許多工具用于發現和理解新功能。Emacs更像是一個包的組合體，由社區的許多人員共同維護。Lisp語言在這當中扮演了重要的抽象邊界的角色。

另外還有兩個類似的架構：Eclipse和Firefox

Eclipse

Eclipse實際上是一個開發環境的框架，它本身沒有提供任何相關功能。通過Java Development Tools等類型的插件，Eclipse就可以對軟件開發提供大量廣泛的支持，而這正是Emacs所欠缺的。

Eclipse為每個插件的輸入和顯示都提供了非常底層的支持，這允許插件實現更加復雜的功能，但也帶來了問題：

Eclipse的插件開發是不安全的，而這正是Emacs具備的。一個充滿bug的插件會讓Eclispe崩潰，而在Emacs中用戶可以終止這樣的插件，并且用戶的數據不會被破壞。

Eclipse插件間的結構比較復雜，這對插件作者是個挑戰。

插件需要足夠的樣板文件代碼。Eclipse中有個幫助大家編寫插件的插件Eclipse Plug-in Development Environment，但這并不能降低底層接口的復雜性。

這引了一些思考。在插件中究竟應該使用哪類接口？插件開發人員應該在怎樣的抽象級別上開發，能否更接近問題？如果保護數據不被充滿bug的插件破壞？

Firefox

Firefox作為現代的瀏覽器，支持JavaScript動態的修改頁面，這一點很像Emacs中的Lisp和緩沖區。不過，Firefox更加徹底地讓自己的用戶界面，以及許多內置功能都使用JavaScript來實現。

這也引起一些思考。在所有使用插件的程序中，插件的開發語言是不是為程序添加功能最好的方法？如果不是，為什么？

感想

引用William J. Mitchell為此書所寫的文章：

“好的建筑師不是通過隨意的、蠻力的方式來構造他們的設計，他們肯定會避免笨拙的做法。”“在漂亮的建筑作品所表現出來的不同和復雜性背后，你通常會發現一些關于功能組織和規范秩序的簡單而優雅的原則。發現這些原則需要思考，而思考正是建筑的快樂和經驗的關鍵部分。”

“如果你能弄明白這些原則，就可以通過某種標準編程語言中同樣優雅的幾行代碼構造出這些作品的模型；但如果你弄不明白這些原則，那么肯定要編寫更長的、不包含那么多深刻見解的代碼。”

“建筑師會仰慕那些應用了簡單優雅原則來實現許多復雜性的架構之美。類似地，軟件架構師和程序員也會仰慕那些清晰而準確執行了許多復雜任務的代碼之美。科學家會仰慕那些描述了各種不同現象的簡單法則之美和它們的解釋能力。”

架構之美在于其簡潔深刻地描述和解決現實的軟件設計問題，無論是它為軟件開發人員減少的麻煩，還是本身形式上的和諧和整齊，都足以讓人賞心悅目。

by Hao Fu

轉載于:https://www.cnblogs.com/MSRA_SE_TEAM/archive/2011/02/27/1966448.html

總結

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

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