探尋軟體的永恆之道 (轉)[@more@]

探尋的永恆之道

——評介《建築的永恆之道》/editor/Editor.htm#_ftn1" name=_ftnref1>[1]

撰文/透明:namespace prefix = o ns = "urn:schemas--com::office" />

從說起

“模式”這個詞進入中國者的視野，是從《設計模式》一書開始的。2000年9月，中國的軟體開發圖書市場還遠不如今天繁榮，相信這本書給絕大多數人的都是一種耳目一新的感覺。突然之間看到如此之多精緻優雅的解決方案，足以令長期苦苦探索設計之路的開發者們“漫卷詩書喜欲狂”了。

在那個時候，我也是模式的痴迷者之一。還記得2001年，我和朋友的通訊中多次表現出這樣的痴迷。下面是我2001年10月給朋友Windy的一封信：

對“面向模式的設計”的開悟，在十三陵。

站在長陵的綾恩殿，宏大的建築，給我一種鵜鶘灌頂的感悟。那天John Vlisss說，Christopher Alexander曾經說中國的建築給了他很多靈感。今天，我想我抓到了一點大師的感觸。

繁複的構造，精巧的設計，卻能天衣無縫的組成如此完美的建築。無疑這是設計的成功。仔細觀察之下，發現對於各種各樣的建築，其組成元件——欞椽梁柱——卻都是毫無二致。這是多麼高的複用程度！這體現了多麼成熟的設計體系！

……

在公路邊，一些建築工人在建造一組仿古的房屋。朝代更替，光陰流逝，但工人們仍然能夠完美的仿造四百年前的建築。因為他們一代代流傳著精確而形象的模式語言。

儘管我看Shalloway的Design Patterns Explained已經有一段時間，在今天，我終於知道為什麼他如此鍾情於Alexander的建築模式了。

可惜，由於缺乏一種文化的積澱，《設計模式》的讀者們（包括我在內）都患上了消化不良。我大膽估計，《設計模式》在中國軟體業造成的負面效果絕不少於其正面效果。Alan Shalloway曾經說，“模式”並不僅僅限於“設計”，甚至“設計”二字正是導致最多誤會的根源；John Vlissides在他的Pattern Hatching中列舉了對模式的“十大誤解”，其中提到“模式並不僅僅是一種解決方案”。但是，有多少人知道，為什麼？

正是因為缺乏必要的背景知識，中國開發者對模式的瞭解往往是片面的甚至是錯誤的。如果把模式僅僅視為一種解決方案、或者一種反覆出現的情況的總結，那麼它頂多只對軟體開發有一定的幫助或者指導意義；如果只把模式作為預先（up-front）設計的方案，它甚至會導致過分工程（over-engineering）。總而言之，模式頂多只能算一種“好東西”，至於“永恆之道”這種溢美之詞，即使最鍾情於模式如我，也是不敢出口的。

建築的永恆之道

在面對一門有數十年思想基礎和十餘年發展歷史的學科時，我們必須承認自己的淺薄，我們必須不斷學習。同時，我們必須有自己的思想。蘇格拉底說：“我們無知，所以我們有智慧。”

為了真正理解GoF的思想，為了真正理解模式的思想，我們有必要先深入其思想基礎。於是，我翻開了手上的書。於是，我看到了與我以往的理解完全不同的知識，我看到了一個嶄新的世界。

記得上面的一個問題嗎？“模式並不僅僅是一個解決方案”。這句話是什麼意思？請看下面這段話：

……模式形成了一種語言。

從數學觀點看，最簡單的語言是一個包括兩個系列的系統：

1.  一系列要素或符號。

2.  組合這些符號的一系列規則。

然而，……模式既是要素，也是規則，所以規則和要素不可分。模式就是要素。每一模式也是一個規則，它描述了本身也是其他模式的要素的可能的排列。

於是豁然開朗。從最初的定義開始，模式就不僅僅是解決方案，而是一種完整的語言。作為解決方案，模式構成了語言的要素；而作為語言規則時，模式的意義同樣重要，甚至更加重要。而這個方面常常被《設計模式》的讀者們忽略了。

僅從書名就可以看出，作者把模式當成“建築的永恆之道”——這種說法是否有點太不謙虛了？請看作者的解釋：

有人已告訴我們，優秀的建築與低劣的建築，優秀的城市與低劣的城市之間沒有客觀的差別。

其實，建築、城市的好壞之別是一個客觀的問題……不過易於理解，為什麼人們如此堅信好劣建築之別沒有單一堅實的基礎。

這是因為產生這種差別的獨特的中心特質無法命名。

（為什麼這種特質無法命名？）

把（這種）無名特質想象為一點，我們試的每個詞作為一個橢圓。每個橢圓包括這點，但每個橢圓也包括許多遠離此點的其他的意義。

因為每個詞總是像這樣的一個橢圓，所以每個詞對於作為點的特質來說，總是太空泛，太不明確，範圍太大。沒有一個詞可以表達無名特質，因為特質太特殊，詞太廣泛了。但是，它是存在於任何人、任何東西之中的最重要的特質。

很明顯，這裡所說的“好”的建築和“差”的建築，都不包含結構有缺陷的“豆腐渣工程”。在結構工程學能夠保證結構的穩固、健壯之後，建築師們想到的便是如何讓建築真正滿足人的需要。在書中，作者多次表示，儘管現代建築有極其優秀的結構，卻缺乏優秀的設計，導致大量的建築違揹人的本性。

我們已經說到了“人的本性”。那麼，建築中“人的本性”在哪裡？它就在數千年流傳的模式語言中。一個特定的模式，在特定的場景下，輔以特定的相關模式，它就是符合人的本性的，因為模式是“允許其自身內力自我疏解”的，而模式語言又是有活力、能夠自我發展的。所以，基於模式設計、設計反向影響模式語言，這樣的過程正是“建築的永恆之道”。

在此有些個人見解：我們已經太習慣於IT圖書那種填鴨式的教學方法了，我們已經太習慣於“一本應用、一本進階原理、一本參考資料”的讀書方式了。再說一次，當我們面對Christopher Alexander這些人文氣息濃厚的技術書籍時，我們必須承認自己的淺薄和無知，我們必須用自己的智慧來思考。中國人最擅長邏輯思維，是以中國人也最容易被一些似乎有意義的詞彙矇蔽雙眼而陷入邏輯先驗不能自拔。當《建築的永恆之道》在一開始就告訴你“這種中心特質”無法命名的時候，你是不是很不能習慣？繼續讀下去，讓你快要生鏽的大腦運轉起來吧。

回到我們的模式

我這裡所說的“我們的模式”，是指“軟體開發中的模式”。介紹了這麼多建築學中的模式，對於軟體開發者有什麼意義嗎？或者說得更直白一些，模式會是“軟體的永恆之道”嗎？對此，我沒有答案，只有討論。不過我相信，沒有人能夠知道真理，有討論、有思考，我們就能離真理更近一些。

由於此書成於1979年，作者又是一位建築學家，書中自然也無法給出關於軟體開發的答案，仍然只能靠讀者自己去思考。讀完兩遍之後，我的心得大約有以下幾點：

l  和建築結構一樣，軟體中亦有諸多的“內力”。和建築設計一樣，軟體設計也應該努力疏解系統中的內力，使系統趨於穩定、有生氣。一切的軟體設計都應該由此出發。

l  任何系統都需要有變化，任何系統都會走向死亡。作為設計者，應該擁抱變化、利用變化，而不是逃避變化。

l  好的軟體只能“產生”而不能“創造”，我們所能做的只是用一個相對好的過程，儘量使軟體朝向好的方向發展。從這個角度來說，開發的迭代週期越短越好。

l  軟體的工業化使軟體僵死、失去“無名特質”、謬誤百出、脫離現實。透過規程、制度來控制，只會使系統內力無從疏解，最終走向崩潰。

l  ……

我好象沒有提到模式？因為整本書講的都是模式。至於如何在軟體的領域中看待模式，那需要你自己去思考、去體會了。

模式到底是不是軟體的永恆之道？最終，我還是無法給出一個答案。但是，我相信，充分理解模式語言，充分理解模式語言和設計的關係，會幫助我們提高設計能力，也會幫助我們豐富模式語言。

未完的結尾

本文即將結束。作為對一本書的介紹，我並沒有介紹它的著、譯質量。不是疏忽，實在是不必說。作者Christopher Alexander用了14年的時間來撰寫此書，譯者趙冰用了數年的時間來翻譯此書——我們所看的IT圖書，翻譯週期極少有達到一年的。還需要懷疑這本書的質量嗎？

在讀完第一遍以後，我寫過一篇名為《“軟體藍領”批判》的讀書心得，引起了許多爭論。可惜，參與爭論的網友，絕大多數並沒有理解我寫那篇文章的背景知識，所以大半的討論都沒有意義。在此，我挑選最有意義的一個回覆來回答，權當為此文作結，也希望張巖先生能看到這篇文章。

張巖對我說：

Alexander是個建築師，建築師關心的是建築如何能符合人的需要，也就是建築的“軟”質量。至於建築的“硬”質量，是由結構工程師來確保的，建築師既沒有能力，也沒有責任對建築的“硬”質量負責。因此建築師的地位類似於軟體工程中的總體設計師或曰架構設計師（現在不是也叫Architect了麼？），在這一族群裡當然沒有所謂藍領的容身之地。但軟體就沒有“硬”質量的要求了麼？當然是有的，所謂編碼強度是也。不當機、不、不誤操作等等。這些是由員來保證的，Architect同樣也管不到這一段。因此通常意義上的Software Enginner或者Programmer相當於建築中的結構工程師的角色。這些人的思維方式應該是內聚的，不能具有發散性，否則“硬”質量無從保證。而模組也是在這一層次上才開始引入的。

要知道，在建築開發過程中，建築師是最不受工程化方法的人。因此如果討論工程化方法，是不應該用建築師的思維方式去類比的。建築史上有段“佳話”：悉尼歌劇院，建築師的發散性思維害苦了結構師，結果整個建築超預算超了一個數量級！但建築落成之後的收益卻比原先預計的高了一個數量級。因此創造性是“建築師的武器、結構師的噩夢”。建築與結構是貫穿建築界始終的一對矛盾，在軟體設計中同樣存在類似的問題。因此僅僅以建築學的視角看問題，我個人以為是有點偏頗的。

我在此回答：

你的回覆告訴了我很多以前不知道的知識。帶著這些知識，我又讀了一遍《建築的永恆之道》。並且，我想我找到了答案。

建築師不受工程化方法約束，但任何人都受自己的模式語言約束，而模式語言本身是受工程化方法約束的。悉尼歌劇院的例子，是在擴充模式語言，這是非常罕見的。當模式語言擴充之後，再利用這些模式語言來建築，就能得到“質量提升了一個數量級”的建築，成本卻不會再“超一個數量級”。不知道你最近去過大運村那邊沒有？PhilCox在那邊設計了一個名叫“錦秋知春”的小區，採用了很多悉尼歌劇院中曾經採用過的元素（或者叫模式），相信它的成本是不會超過預算一個數量級的，對吧？之所以在悉尼歌劇院的例子中出現這樣的窘境，我相信是因為結構工程的滯後——人的思想總是超前的，我們應該讓滯後、僵硬的物理去適應超前的、有生氣的思想，而不是相反，對嗎？

 

---

現在讀者可以在中國互動出版網（）購買?id=6374">《建築的永恆之道》一書及其姐妹篇（A Pattern Language）和（The Oregon Experiment）

Eric Gamma等著，李英軍等譯，《設計模式》（Design Patterns），機械工業出版社2000年9月。

2002年4月30日UMLChina主辦的Alan Shalloway網上交流記錄，/Shalloway.pdf">

John Vlissides，《模式的十大誤解》，

Christopher Alexander著，趙冰譯，《建築的永恆之道》（The Timeless Way of Building），智慧財產權出版社2002年2月，第144頁到第145頁。

Christopher Alexander著，趙冰譯，《建築的永恆之道》（The Timeless Way of Building），智慧財產權出版社2002年2月，第21頁到第30頁。

http://expert.csdn.net/develop/Article/13/13656.shtm