《架構之美》讀後感

Beautiful ArchitectureLeading 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