语源科技BlogJava-Boshhttp://www.blogjava.net/bosh/zh-cnWed, 29 Apr 2026 03:36:15 GMTWed, 29 Apr 2026 03:36:15 GMT60[转载]探寻软件的永恒之道 http://www.blogjava.net/bosh/archive/2005/08/15/10124.htmlBosh's blogBosh's blogMon, 15 Aug 2005 03:33:00 GMThttp://www.blogjava.net/bosh/archive/2005/08/15/10124.htmlhttp://www.blogjava.net/bosh/comments/10124.htmlhttp://www.blogjava.net/bosh/archive/2005/08/15/10124.html#Feedback0http://www.blogjava.net/bosh/comments/commentRss/10124.htmlhttp://www.blogjava.net/bosh/services/trackbacks/10124.html [转载]探寻软件的永恒之道 
   

探寻软件的永恒之道
――评介《建筑的永恒之道》

撰文/透明

从模式说起

“模式”这个词进入中国软件开发者的视野，是从《设计模式》[2]一书开始的。2000年9月，中国的软件开发图书市场还远不如今天繁荣，相信这本书给绝大多数人的都是一种耳目一新的感觉。突然之间看到如此之多精致优雅的解决方案，足以令长期苦苦探索设计之路的开发者们“漫卷诗书喜欲狂”了。

在那个时候，我也是模式的痴迷者之一。还记得2001年，我和朋友的通信中多次表现出这样的痴迷。下面是我2001年10月给朋友Windy的一封信：

对“面向模式的设计”的开悟，在十三陵。

站在长陵的绫恩殿，宏大的建筑，给我一种鹈鹕灌顶的感悟。那天John Vlissides说，Christopher Alexander曾经说中国的建筑给了他很多灵感。今天，我想我抓到了一点大师的感触。

繁复的构造，精巧的设计，却能天衣无缝的组成如此完美的建筑。无疑这是设计的成功。仔细观察之下，发现对于各种各样的建筑，其组成元件――棂椽梁柱――却都是毫无二致。这是多么高的复用程度！这体现了多么成熟的设计体系！

……

在公路边，一些建筑工人在建造一组仿古的房屋。朝代更替，光阴流逝，但工人们仍然能够完美的仿造四百年前的建筑。因为他们一代代流传着精确而形象的模式语言。

尽管我看Shalloway的Design Patterns Explained已经有一段时间，在今天，我终于知道为什么他如此钟情于Alexander的建筑模式了。


可惜，由于缺乏一种文化的积淀，《设计模式》的读者们（包括我在内）都患上了消化不良。我大胆估计，《设计模式》在中国软件业造成的负面效果绝不少于其正面效果。Alan Shalloway曾经说，“模式”并不仅仅限于“设计”，甚至“设计”二字正是导致最多误会的根源[3]；John Vlissides在他的Pattern Hatching中列举了对模式的“十大误解”，其中提到“模式并不仅仅是一种解决方案”[4]。但是，有多少人知道，为什么？

正是因为缺乏必要的背景知识，中国开发者对模式的了解往往是片面的甚至是错误的。如果把模式仅仅视为一种解决方案、或者一种反复出现的情况的总结，那么它顶多只对软件开发有一定的帮助或者指导意义；如果只把模式作为预先（up-front）设计的方案，它甚至会导致过分工程（over-engineering）。总而言之，模式顶多只能算一种“好东西”，至于“永恒之道”这种溢美之词，即使最钟情于模式如我，也是不敢出口的。

建筑的永恒之道

在面对一门有数十年思想基础和十余年发展历史的学科时，我们必须承认自己的浅薄，我们必须不断学习。同时，我们必须有自己的思想。苏格拉底说：“我们无知，所以我们有智慧。”

为了真正理解GoF的思想，为了真正理解模式的思想，我们有必要先深入其思想基础。于是，我翻开了手上的书。于是，我看到了与我以往的理解完全不同的知识，我看到了一个崭新的世界。

记得上面的一个问题吗？“模式并不仅仅是一个解决方案”。这句话是什么意思？请看下面这段话：

……模式系统形成了一种语言。

从数学观点看，最简单的语言是一个包括两个系列的系统：

1. 一系列要素或符号。

2. 组合这些符号的一系列规则。

然而，……模式既是要素，也是规则，所以规则和要素不可分。模式就是要素。每一模式也是一个规则，它描述了本身也是其他模式的要素的可能的排列。[5]

于是豁然开朗。从最初的定义开始，模式就不仅仅是解决方案，而是一种完整的语言。作为解决方案，模式构成了语言的要素；而作为语言规则时，模式的意义同样重要，甚至更加重要。而这个方面常常被《设计模式》的读者们忽略了。

仅从书名就可以看出，作者把模式当成“建筑的永恒之道”――这种说法是否有点太不谦虚了？请看作者的解释：

有人已告诉我们，优秀的建筑与低劣的建筑，优秀的城市与低劣的城市之间没有客观的差别。

其实，建筑、城市的好坏之别是一个客观的问题……不过易于理解，为什么人们如此坚信好劣建筑之别没有单一坚实的基础。

这是因为产生这种差别的独特的中心特质无法命名。

（为什么这种特质无法命名？）

把（这种）无名特质想象为一点，我们试的每个词作为一个椭圆。每个椭圆包括这点，但每个椭圆也包括许多远离此点的其他的意义。

因为每个词总是像这样的一个椭圆，所以每个词对于作为点的特质来说，总是太空泛，太不明确，范围太大。没有一个词可以表达无名特质，因为特质太特殊，词太广泛了。但是，它是存在于任何人、任何东西之中的最重要的特质。[6]

很明显，这里所说的“好”的建筑和“差”的建筑，都不包含结构有缺陷的“豆腐渣工程”。在结构工程学能够保证结构的稳固、健壮之后，建筑师们想到的便是如何让建筑真正满足人的需要。在书中，作者多次表示，尽管现代建筑有极其优秀的结构，却缺乏优秀的设计，导致大量的建筑违背人的本性。

我们已经说到了“人的本性”。那么，建筑中“人的本性”在哪里？它就在数千年流传的模式语言中。一个特定的模式，在特定的场景下，辅以特定的相关模式，它就是符合人的本性的，因为模式是“允许其自身内力自我疏解”的，而模式语言又是有活力、能够自我发展的。所以，基于模式设计、设计反向影响模式语言，这样的过程正是“建筑的永恒之道”。

在此有些个人见解：我们已经太习惯于IT图书那种填鸭式的教学方法了，我们已经太习惯于“一本入门应用、一本进阶原理、一本参考资料”的读书方式了。再说一次，当我们面对Christopher Alexander这些人文气息浓厚的技术书籍时，我们必须承认自己的浅薄和无知，我们必须用自己的智慧来思考。中国人最擅长逻辑思维，是以中国人也最容易被一些似乎有意义的词汇蒙蔽双眼而陷入逻辑先验不能自拔。当《建筑的永恒之道》在一开始就告诉你“这种中心特质”无法命名的时候，你是不是很不能习惯？继续读下去，让你快要生锈的大脑运转起来吧。

回到我们的模式

我这里所说的“我们的模式”，是指“软件开发中的模式”。介绍了这么多建筑学中的模式，对于软件开发者有什么意义吗？或者说得更直白一些，模式会是“软件的永恒之道”吗？对此，我没有答案，只有讨论。不过我相信，没有人能够知道真理，有讨论、有思考，我们就能离真理更近一些。

由于此书成于1979年，作者又是一位建筑学家，书中自然也无法给出关于软件开发的答案，仍然只能靠读者自己去思考。读完两遍之后，我的心得大约有以下几点：

----和建筑结构一样，软件中亦有诸多的“内力”。和建筑设计一样，软件设计也应该努力疏解系统中的内力，使系统趋于稳定、有生气。一切的软件设计都应该由此出发。

----任何系统都需要有变化，任何系统都会走向死亡。作为设计者，应该拥抱变化、利用变化，而不是逃避变化。

----好的软件只能“产生”而不能“创造”，我们所能做的只是用一个相对好的过程，尽量使软件朝向好的方向发展。从这个角度来说，开发的迭代周期越短越好。

----软件的工业化使软件僵死、失去“无名特质”、谬误百出、脱离现实。通过规程、制度来控制，只会使系统内力无从疏解，最终走向崩溃。

----……

我好象没有提到模式？因为整本书讲的都是模式。至于如何在软件的领域中看待模式，那需要你自己去思考、去体会了。

模式到底是不是软件的永恒之道？最终，我还是无法给出一个答案。但是，我相信，充分理解模式语言，充分理解模式语言和设计的关系，会帮助我们提高设计能力，也会帮助我们丰富模式语言。

未完的结尾

本文即将结束。作为对一本书的介绍，我并没有介绍它的著、译质量。不是疏忽，实在是不必说。作者Christopher Alexander用了14年的时间来撰写此书，译者赵冰用了数年的时间来翻译此书――我们所看的IT图书，翻译周期极少有达到一年的。还需要怀疑这本书的质量吗？

在读完第一遍以后，我写过一篇名为《“软件蓝领”批判》[7]的读书心得，引起了许多争论。可惜，参与争论的网友，绝大多数并没有理解我写那篇文章的背景知识，所以大半的讨论都没有意义。在此，我挑选最有意义的一个回复来回答，权当为此文作结，也希望张岩先生能看到这篇文章。

张岩对我说：

Alexander是个建筑师，建筑师关心的是建筑如何能符合人的需要，也就是建筑的“软”质量。至于建筑的“硬”质量，是由结构工程师来确保的，建筑师既没有能力，也没有责任对建筑的“硬”质量负责。因此建筑师的地位类似于软件工程中的总体设计师或曰架构设计师（现在不是也叫Architect了么？），在这一族群里当然没有所谓蓝领的容身之地。但软件就没有“硬”质量的要求了么？当然是有的，所谓编码强度是也。不死机、不溢出、不误操作等等。这些是由程序员来保证的，Architect同样也管不到这一段。因此通常意义上的Software Enginner或者Programmer相当于建筑中的结构工程师的角色。这些人的思维方式应该是内聚的，不能具有发散性，否则“硬”质量无从保证。而模块也是在这一层次上才开始引入的。

要知道，在建筑开发过程中，建筑师是最不受工程化方法约束的人。因此如果讨论工程化方法，是不应该用建筑师的思维方式去类比的。建筑史上有段“佳话”：悉尼歌剧院，建筑师的发散性思维害苦了结构师，结果整个建筑超预算超了一个数量级！但建筑落成之后的收益却比原先预计的高了一个数量级。因此创造性是“建筑师的武器、结构师的噩梦”。建筑与结构是贯穿建筑界始终的一对矛盾，在软件设计中同样存在类似的问题。因此仅仅以建筑学的视角看问题，我个人以为是有点偏颇的。


我在此回答：

你的回复告诉了我很多以前不知道的知识。带着这些知识，我又读了一遍《建筑的永恒之道》。并且，我想我找到了答案。

建筑师不受工程化方法约束，但任何人都受自己的模式语言约束，而模式语言本身是受工程化方法约束的。悉尼歌剧院的例子，是在扩充模式语言，这是非常罕见的。当模式语言扩充之后，再利用这些模式语言来建筑，就能得到“质量提升了一个数量级”的建筑，成本却不会再“超一个数量级”。不知道你最近去过大运村那边没有？Philip Cox在那边设计了一个名叫“锦秋知春”的小区，采用了很多悉尼歌剧院中曾经采用过的元素（或者叫模式），相信它的成本是不会超过预算一个数量级的，对吧？之所以在悉尼歌剧院的例子中出现这样的窘境，我相信是因为结构工程的滞后――人的思想总是超前的，我们应该让滞后、僵硬的物理去适应超前的、有生气的思想，而不是相反，对吗？
--------------------------------------------------------------------------------

[1] 现在读者可以在中国互动出版网（http://www.china-pub.com/）购买《建筑的永恒之道》一书及其姐妹篇《建筑模式语言》（A Pattern Language）和《俄勒冈实验》（The Oregon Experiment）

[2] Eric Gamma等著，李英军等译，《设计模式》（Design Patterns），机械工业出版社2000年9月。

[3] 2002年4月30日UMLChina主办的Alan Shalloway网上交流记录，http://gigix.cool2u.net/download/Shalloway.pdf

[4] John Vlissides，《模式的十大误解》，http://gigix.cool2u.net/download/topten.pdf

[5] Christopher Alexander著，赵冰译，《建筑的永恒之道》（The Timeless Way of Building），知识产权出版社2002年2月，第144页到第145页。

[6] Christopher Alexander著，赵冰译，《建筑的永恒之道》（The Timeless Way of Building），知识产权出版社2002年2月，第21页到第30页。

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

Bosh's blog 2005-08-15 11:33 发表评论
]]>