772
社区成员
2.8w+
社区内容
- 主页
转载 《建筑的永恒之道》读后感
原文在http://www.mblog.com/vrealtech/
这几天又把《建筑的永恒之道》拿出来看了一下。这是一本很好的书，虽然是讲建筑的，但是对做软件开发的也有很大帮助。实际上这本书是在阐述一种哲学观点。
上一次读是在学完《设计模式》之后不久，对模式的理解是：它是一种前人经验的积累，比如房子坐北朝南最初是为了接受更多的阳光，由于这是一个很好的经验，慢慢被广为接受，形成了模式。还有房顶的样式，飞檐是引导雨水的，成为模式后渐渐变为了一种审美上的东西。也就是说模式是一种前人应用经验的精炼，能够减少设计时候的弯路。
这次看又体味到了一种新的观点，模式为人广为接受以后，形成了一种共同的语言，它将一种模式的细节包含在一个短短的短语之中，人们都能理解这短语之后的各种细节。人们在交流的时候使用这种语言可以免去细节的阐述，而且能更明确的理解对方的意图。
应用在软件上首先是设计模式，它的命名包含了如何建立Class的细节，当人们都理解后，在描述设计的时候就不用再去阐述细节了。
另一种是软件使用者层面的，比如“windows式的开始菜单”、“HTML超链接式的命令列表”。可以非常直观的描述对操作界面的要求，而且比直接描述更准确，不容易引起误解。这种模式不一定是最优实践积累下来的，而是一种习惯的延续。由于用户习惯了一种操作风格，所以才会有这种要求。这个层面是我以前没有想到过的。在书中写道：“在有生气语言的城市中，模式语言如此广泛，以至每个人都可以使用它。”提到了模式语言非常简单所以每个人都可以理解，还提到了现代模式语言的瓦解，以至于最终使得设计工作变得非常专业，语言成为私有，所以无法沟通。同时人们又害怕自己犯愚蠢的错误而更加退缩。
我在很多项目里面都感觉很难和客户沟通，很多客户对我们的提议没有任何概念，无法判断好坏，同时又以怀疑的眼光看待这些提议，迟迟不敢下决定。一方面我们感到不被信任，心中愤愤不平。客户总觉得我们在回避困难，不愿意提供好的服务。这就是因为双方使用的共同语言太少，无法相互理解对方的意图。软件这一行范围很广，术语太专业太复杂，我们作为从业者都无法理解所有的术语更不要提客户了。需要一种简单的广泛的模式语言来弥合客户和系统分析人员的鸿沟。“windows式的开始菜单”、“HTML超链接式的命令列表”都是很好的模式，但是有的模式太微观，很难让客户对整体模式作出描述。所以作出的很多软件往往缺乏整体风格，显得很凌乱而且使用不便（每个部分都要重新学习使用方法，重新适应操作习惯）。更好的描述是“XXX类型的编辑器”，“XXX式的结果表示”，“使用XXX方式连接两个窗口”等等。
书中还提到了模式语言的包容性，就是各种模式是层层嵌套的。宏观上有一个区域的模式语言，然后再细一些是城市的模式、社区模式、邻里模式、建筑群模式、建筑和房间模式一直到构造细部模式。软件也是这样，有宏观的构架模式，用户界面总体风格模式，再细下去有模块划分模式、模块内部Class构造模式、界面操作模式，再往下有程序内部成员的模式，代码的模式。很难想象一个设计师能把这么复杂的一切全都安排的妥妥当当的。这么多的模式语言也是一个人不可能全会的。所以软件的分工非常重要。而且不能轻视任何地方。
这几天又把《建筑的永恒之道》拿出来看了一下。这是一本很好的书，虽然是讲建筑的，但是对做软件开发的也有很大帮助。实际上这本书是在阐述一种哲学观点。
上一次读是在学完《设计模式》之后不久，对模式的理解是：它是一种前人经验的积累，比如房子坐北朝南最初是为了接受更多的阳光，由于这是一个很好的经验，慢慢被广为接受，形成了模式。还有房顶的样式，飞檐是引导雨水的，成为模式后渐渐变为了一种审美上的东西。也就是说模式是一种前人应用经验的精炼，能够减少设计时候的弯路。
这次看又体味到了一种新的观点，模式为人广为接受以后，形成了一种共同的语言，它将一种模式的细节包含在一个短短的短语之中，人们都能理解这短语之后的各种细节。人们在交流的时候使用这种语言可以免去细节的阐述，而且能更明确的理解对方的意图。
应用在软件上首先是设计模式，它的命名包含了如何建立Class的细节，当人们都理解后，在描述设计的时候就不用再去阐述细节了。
另一种是软件使用者层面的，比如“windows式的开始菜单”、“HTML超链接式的命令列表”。可以非常直观的描述对操作界面的要求，而且比直接描述更准确，不容易引起误解。这种模式不一定是最优实践积累下来的，而是一种习惯的延续。由于用户习惯了一种操作风格，所以才会有这种要求。这个层面是我以前没有想到过的。在书中写道：“在有生气语言的城市中，模式语言如此广泛，以至每个人都可以使用它。”提到了模式语言非常简单所以每个人都可以理解，还提到了现代模式语言的瓦解，以至于最终使得设计工作变得非常专业，语言成为私有，所以无法沟通。同时人们又害怕自己犯愚蠢的错误而更加退缩。
我在很多项目里面都感觉很难和客户沟通，很多客户对我们的提议没有任何概念，无法判断好坏，同时又以怀疑的眼光看待这些提议，迟迟不敢下决定。一方面我们感到不被信任，心中愤愤不平。客户总觉得我们在回避困难，不愿意提供好的服务。这就是因为双方使用的共同语言太少，无法相互理解对方的意图。软件这一行范围很广，术语太专业太复杂，我们作为从业者都无法理解所有的术语更不要提客户了。需要一种简单的广泛的模式语言来弥合客户和系统分析人员的鸿沟。“windows式的开始菜单”、“HTML超链接式的命令列表”都是很好的模式，但是有的模式太微观，很难让客户对整体模式作出描述。所以作出的很多软件往往缺乏整体风格，显得很凌乱而且使用不便（每个部分都要重新学习使用方法，重新适应操作习惯）。更好的描述是“XXX类型的编辑器”，“XXX式的结果表示”，“使用XXX方式连接两个窗口”等等。
书中还提到了模式语言的包容性，就是各种模式是层层嵌套的。宏观上有一个区域的模式语言，然后再细一些是城市的模式、社区模式、邻里模式、建筑群模式、建筑和房间模式一直到构造细部模式。软件也是这样，有宏观的构架模式，用户界面总体风格模式，再细下去有模块划分模式、模块内部Class构造模式、界面操作模式，再往下有程序内部成员的模式，代码的模式。很难想象一个设计师能把这么复杂的一切全都安排的妥妥当当的。这么多的模式语言也是一个人不可能全会的。所以软件的分工非常重要。而且不能轻视任何地方。
...全文
meijing 2004年08月20日
哈哈。
我说怎么这么说得这么好，仔细一看，原来是阎博士
最近又看了看您的大作。
感觉还是有收获。不过老实说，个人感觉要是语言再简练些就更好了。
我说怎么这么说得这么好，仔细一看，原来是阎博士
最近又看了看您的大作。
感觉还是有收获。不过老实说，个人感觉要是语言再简练些就更好了。
yingshis 2004年08月20日
up
HWHuang 2004年08月19日
学习中……
crazyeagle 2004年08月17日
up
flying_sunny 2004年07月19日
up
jeffyan77 2004年07月07日
论坛因为技术问题暂时关闭
有事发短消息
有事发短消息
niky8053 2004年07月04日
UP
zhuma 2004年07月04日
好久没见到jeffyan前辈了
本来有些事想请教您
可您的个人论坛怎么也上不去了
搬家了？
本来有些事想请教您
可您的个人论坛怎么也上不去了
搬家了？
rtdb 2004年06月30日
嘿嘿，讲哲学阎博士果然是专家。
jeffyan77 2004年06月30日
人们说的话都差不多，但是代表的思想不一定相同。你到底读懂了Alexander没有，没有人知道。
Alexander的所谓生长，是说像胚胎一样，从一开始就是一个整体，逐步分化，是从整体到部分，而不是从部分到整体。
一个建筑物的设计一开始是设计师头脑中的一个影像，然后这个影像逐步清晰化，最后落实到纸上，成为有血有肉的设计图。没有一个设计师是现在头脑中看到建筑的一个墙脚，然后由墙角开始变成整个房屋的。就好像婴儿是从一个受精卵开始不断分裂，从整体不断分化出部分来。他一开始就是一个活体，一直就是活体，直到出生。自然界从来就没有一种生物的胚胎是先产生一只耳朵，然后另一只耳朵，最后组装成活体。
这也就是道家的哲学。道家说一生二，二胜三，三生万物，这些一、二、三都是活体。
传统的西方哲学描述一个相反的过程，从部分开始，逐步生成整体。这是发源于古希腊的几何学世界观，描述的是一个机械化的生产过程，首先你造出一个玩具熊的耳朵，然后造出另一只耳朵，一只腿，另一只腿，最后组装起来，成为一个玩具熊。它不是自然界的生长过程。
软件设计应当更为接近于Alexander哲学，也就是道家哲学。首先你的头脑中有一个整体影像，然后分化和具体化成各个部分细节。
一个胚胎能够从单个的细胞出发，分化出成千上万个不同功能的细胞来，是因为他们内部带有遗传物质，他们受到遗传物质的支配。一个软体设计之所以能够从整体到部分，是因为受到模式和模式语言的支配。
你可能没有学过模式，但是你头脑中有模式。你的设计会反复重复一些相同的特点，无论是整体的还是细节的。这些就是因为你头脑中的模式在不断涌现。
Alexander的所谓生长，是说像胚胎一样，从一开始就是一个整体，逐步分化，是从整体到部分，而不是从部分到整体。
一个建筑物的设计一开始是设计师头脑中的一个影像，然后这个影像逐步清晰化，最后落实到纸上，成为有血有肉的设计图。没有一个设计师是现在头脑中看到建筑的一个墙脚，然后由墙角开始变成整个房屋的。就好像婴儿是从一个受精卵开始不断分裂，从整体不断分化出部分来。他一开始就是一个活体，一直就是活体，直到出生。自然界从来就没有一种生物的胚胎是先产生一只耳朵，然后另一只耳朵，最后组装成活体。
这也就是道家的哲学。道家说一生二，二胜三，三生万物，这些一、二、三都是活体。
传统的西方哲学描述一个相反的过程，从部分开始，逐步生成整体。这是发源于古希腊的几何学世界观，描述的是一个机械化的生产过程，首先你造出一个玩具熊的耳朵，然后造出另一只耳朵，一只腿，另一只腿，最后组装起来，成为一个玩具熊。它不是自然界的生长过程。
软件设计应当更为接近于Alexander哲学，也就是道家哲学。首先你的头脑中有一个整体影像，然后分化和具体化成各个部分细节。
一个胚胎能够从单个的细胞出发，分化出成千上万个不同功能的细胞来，是因为他们内部带有遗传物质，他们受到遗传物质的支配。一个软体设计之所以能够从整体到部分，是因为受到模式和模式语言的支配。
你可能没有学过模式，但是你头脑中有模式。你的设计会反复重复一些相同的特点，无论是整体的还是细节的。这些就是因为你头脑中的模式在不断涌现。
tt52 2004年06月29日
up
panq 2004年06月29日
《建筑的永恒之道》读后感之三
读了两遍后，感觉理解的深了一些。
这本书分了三大块，《质》，《门》，《道》。然后还有最后一部分《永恒之道》。
《质》
讨论了所谓“无名特质”。无名，就是无法说出的。阐述了建筑当中存在一种无法精确描述的特质，它是这个行业在漫长的发展过程中积淀下来 的一种东西。说是经验也好，规律也好，或者可以说是一种模式。由于自然条件和生活习惯的制约，建筑不可能天马行空的建造，它的各个方 面必须首先达到合理、实用。那时候没有那么高深的科学，只能在不断的摸索中寻求合理实用。一些合理实用的结构和设计带来了生活上的舒 适，于是被竞相模仿，然后又被不断的改进，再被模仿，当模仿的多了，就被称之为"好"，继而被称之为“美”。这种美就被作为模式一代代流 传了下来。可能最终，人们只知道这种模式是美的，而忘却了其根本的实用价值，但是它的实用价值并没有消亡，而是成为了“无名特质”。当 违反了“无名特质”的时候，不仅仅带来了丑，而且会引起实用价值的降低。
同时“无名特质”是非常复杂的，是一种合力，一种建筑风格是对当地气候、地形、风俗、生活习惯等等综合因素的最佳适应。不是用某一种公 式可以推导出来的。而且人的思维不是连续的、完备的，所以在设计的时候不一定能考虑到所有问题点。而模式则为他提供了一种最佳方 案。
另外，模式并不是放之四海而皆准的，在不同的风土人情下会有不同的最佳方案。
《门》
由于这种“无名特质”的复杂性，没有办法用形式化语言对它的特性进行描述，也很难将它分解。“无名特质”虽然包含了多方面的因素，但是它 是一个整体。幸运的是，“无名特质”所衍生出的模式已经形成了一种概念化的东西，在某些语言中已经有专门的语言来标识一些模式。比如“火 炕”、“佛塔”等等。这种语言已经形成了一种直觉的反射。这种语言提出后，不需要做详尽语言描述，就可以让人想到其基本功能以及样式。使 用这种模式语言能最大的减少用户和施工人员之间的误解。
作者提到了模式语言的消亡，由于现代建筑把设计的权力集中在建筑师手中，再加上各种过于关注微观的或者冰冷的纯理性的理论，使得设计 人员过早地陷入到了细节中，而忽视了用户的真正需求。所以建筑变得死气沉沉。
作者呼吁人们重拾模式语言，恢复建筑的活力。因为这种模式语言是通向永恒之道的大门。
《道》
穿过了门，走上了道。但是这道还不是永恒之道，还取决于你怎么走。作者在这里提出了建筑“生长”的观念。建筑不是静态的，因为随着时代 的发展，环境和生活方式以及习俗的变化导致建筑也要随之变化以适应新的需求。同时作者还引申到了街道，城市的规划设计。提出一切都是 在“生长”的观点。认为事先设计好的东西很可能是僵死的，教条的。
另外还有如何使用手中的模式语言。作者认为模式语言是分层次的，有宏观的，局部的，细部的，微观的等等。使用中不应当混用，而是从高 往低、从宏观往微观一层层的使用。尤其是随着系统的复杂度不断的增加，比如需要建造的不是一个简单的房子，而是一个街区，甚至一个城 市，这种情况下，一个人已经无法同时把握整个系统的所有特性了，就需要分步骤考虑，甚至多个人分工。
《永恒之道》
表面上的理解是不能拘泥于模式语言，领悟得还不是很深。有些像武侠小说中的无招胜有招那种。但是这种不拘泥并不是说使之消亡而使用《 门》里说的那种所谓现代建筑理论。可能是说要去发展新的模式语言。
回想一下前三部分和软件开发行业有不少共同之处。比如无名特质和模式语言，已经在设计模式中被体现，提出了不少简单的模式。确定的复 合模式还很少。不过模式语言在软件开发中应用的还是很少，比如在需求分析的时候，当要描述一个整块的概念时没有合适的模式语言唤起客 户和分析人员共同的概念。所以只能使用列表的方法把特性列出来（这实际上是用一种微观的模式语言来描述宏观概念），但是这些列表往往 是功能上的，会忽略很多非功能上的细节，导致一些误解。
关于《道》的观点用在软件开发里就激进了一些。现在的软件开发往往只关注一次项目，我常常听见有人说：这个项目马上就完了，一切终于 结束了。或者：我们不会承接下次开发和后期维护，糊出来，功能全，没有bug就可以了，不好维护不是我们的事情了。对于有些完美主义的我 听了后心里很不是滋味，难道软件就是糊出来的吗？首先是对客户的不负责，然后也是对自己的不负责，也许应当关注的更远一些。
如何做呢？在一开始就把软件的所有特性甚至将来可能会有的特性做出来？这样的项目肯定会亏本，而且还是做不全：你不是算命先生，无法 预测没有发生的事情。唯一的方法是使用良好的架构，然后让软件在这个架构上茁壮的生长。就如同制定出一个良好的市场机制和法律，经济 才能健康的发展。刚才的观点早已有人提出了，但是还有一个难点就是如何实施，这个问题还在考虑中。
读了两遍后，感觉理解的深了一些。
这本书分了三大块，《质》，《门》，《道》。然后还有最后一部分《永恒之道》。
《质》
讨论了所谓“无名特质”。无名，就是无法说出的。阐述了建筑当中存在一种无法精确描述的特质，它是这个行业在漫长的发展过程中积淀下来 的一种东西。说是经验也好，规律也好，或者可以说是一种模式。由于自然条件和生活习惯的制约，建筑不可能天马行空的建造，它的各个方 面必须首先达到合理、实用。那时候没有那么高深的科学，只能在不断的摸索中寻求合理实用。一些合理实用的结构和设计带来了生活上的舒 适，于是被竞相模仿，然后又被不断的改进，再被模仿，当模仿的多了，就被称之为"好"，继而被称之为“美”。这种美就被作为模式一代代流 传了下来。可能最终，人们只知道这种模式是美的，而忘却了其根本的实用价值，但是它的实用价值并没有消亡，而是成为了“无名特质”。当 违反了“无名特质”的时候，不仅仅带来了丑，而且会引起实用价值的降低。
同时“无名特质”是非常复杂的，是一种合力，一种建筑风格是对当地气候、地形、风俗、生活习惯等等综合因素的最佳适应。不是用某一种公 式可以推导出来的。而且人的思维不是连续的、完备的，所以在设计的时候不一定能考虑到所有问题点。而模式则为他提供了一种最佳方 案。
另外，模式并不是放之四海而皆准的，在不同的风土人情下会有不同的最佳方案。
《门》
由于这种“无名特质”的复杂性，没有办法用形式化语言对它的特性进行描述，也很难将它分解。“无名特质”虽然包含了多方面的因素，但是它 是一个整体。幸运的是，“无名特质”所衍生出的模式已经形成了一种概念化的东西，在某些语言中已经有专门的语言来标识一些模式。比如“火 炕”、“佛塔”等等。这种语言已经形成了一种直觉的反射。这种语言提出后，不需要做详尽语言描述，就可以让人想到其基本功能以及样式。使 用这种模式语言能最大的减少用户和施工人员之间的误解。
作者提到了模式语言的消亡，由于现代建筑把设计的权力集中在建筑师手中，再加上各种过于关注微观的或者冰冷的纯理性的理论，使得设计 人员过早地陷入到了细节中，而忽视了用户的真正需求。所以建筑变得死气沉沉。
作者呼吁人们重拾模式语言，恢复建筑的活力。因为这种模式语言是通向永恒之道的大门。
《道》
穿过了门，走上了道。但是这道还不是永恒之道，还取决于你怎么走。作者在这里提出了建筑“生长”的观念。建筑不是静态的，因为随着时代 的发展，环境和生活方式以及习俗的变化导致建筑也要随之变化以适应新的需求。同时作者还引申到了街道，城市的规划设计。提出一切都是 在“生长”的观点。认为事先设计好的东西很可能是僵死的，教条的。
另外还有如何使用手中的模式语言。作者认为模式语言是分层次的，有宏观的，局部的，细部的，微观的等等。使用中不应当混用，而是从高 往低、从宏观往微观一层层的使用。尤其是随着系统的复杂度不断的增加，比如需要建造的不是一个简单的房子，而是一个街区，甚至一个城 市，这种情况下，一个人已经无法同时把握整个系统的所有特性了，就需要分步骤考虑，甚至多个人分工。
《永恒之道》
表面上的理解是不能拘泥于模式语言，领悟得还不是很深。有些像武侠小说中的无招胜有招那种。但是这种不拘泥并不是说使之消亡而使用《 门》里说的那种所谓现代建筑理论。可能是说要去发展新的模式语言。
回想一下前三部分和软件开发行业有不少共同之处。比如无名特质和模式语言，已经在设计模式中被体现，提出了不少简单的模式。确定的复 合模式还很少。不过模式语言在软件开发中应用的还是很少，比如在需求分析的时候，当要描述一个整块的概念时没有合适的模式语言唤起客 户和分析人员共同的概念。所以只能使用列表的方法把特性列出来（这实际上是用一种微观的模式语言来描述宏观概念），但是这些列表往往 是功能上的，会忽略很多非功能上的细节，导致一些误解。
关于《道》的观点用在软件开发里就激进了一些。现在的软件开发往往只关注一次项目，我常常听见有人说：这个项目马上就完了，一切终于 结束了。或者：我们不会承接下次开发和后期维护，糊出来，功能全，没有bug就可以了，不好维护不是我们的事情了。对于有些完美主义的我 听了后心里很不是滋味，难道软件就是糊出来的吗？首先是对客户的不负责，然后也是对自己的不负责，也许应当关注的更远一些。
如何做呢？在一开始就把软件的所有特性甚至将来可能会有的特性做出来？这样的项目肯定会亏本，而且还是做不全：你不是算命先生，无法 预测没有发生的事情。唯一的方法是使用良好的架构，然后让软件在这个架构上茁壮的生长。就如同制定出一个良好的市场机制和法律，经济 才能健康的发展。刚才的观点早已有人提出了，但是还有一个难点就是如何实施，这个问题还在考虑中。
panq 2004年06月29日
建筑的永恒之道》读后感（二）
"充满生气的城市只能有一个程序产生出来，在这个程序中许多模式被人们创在和保持，而人们又是这些模式的一部分。
"而这意味着，一个有生气的城市的成长和再生是由无数较小的活动建成的。
"在一个共同语言消失的城市中，建造和设计的活动是在少数人手中的，而且是庞大笨拙的。
...
"他是成千上万细小行动的不断的变动，每个行动都在最了解它、最能够使它适应当地情况的人们手中。
(后面还有很多)
——摘自《建筑的永恒之道》第三部分:道 一旦我们建成了大门，我们便可以通过它进入到永恒之道的实践。
软件开发何尝不是一个实践的过程。一个系统是如此复杂，不亚于一个城市。每个模块有自己的角色和分工，就像市井中的形形色色的人，有的提供服务，有的接受服务，有的合作达成目标...。建造和设计如果只在在少数人的手中，必然庞大而笨拙，而且不一定能够最适应当地的情况。这种结构是脆弱的，外强中干，很可能一个小小的事故就使之完全崩溃。但是这种过程不是杂乱的、各自为政的，而是统一在一个整体的全局级别的模式语言中。每个细小的过程在完成自己的过程中，又为整体做出了贡献，使自身投入到更大的过程中。它像一个生命体一样，不断改变，不断完善，不断进化。
"充满生气的城市只能有一个程序产生出来，在这个程序中许多模式被人们创在和保持，而人们又是这些模式的一部分。
"而这意味着，一个有生气的城市的成长和再生是由无数较小的活动建成的。
"在一个共同语言消失的城市中，建造和设计的活动是在少数人手中的，而且是庞大笨拙的。
...
"他是成千上万细小行动的不断的变动，每个行动都在最了解它、最能够使它适应当地情况的人们手中。
(后面还有很多)
——摘自《建筑的永恒之道》第三部分:道 一旦我们建成了大门，我们便可以通过它进入到永恒之道的实践。
软件开发何尝不是一个实践的过程。一个系统是如此复杂，不亚于一个城市。每个模块有自己的角色和分工，就像市井中的形形色色的人，有的提供服务，有的接受服务，有的合作达成目标...。建造和设计如果只在在少数人的手中，必然庞大而笨拙，而且不一定能够最适应当地的情况。这种结构是脆弱的，外强中干，很可能一个小小的事故就使之完全崩溃。但是这种过程不是杂乱的、各自为政的，而是统一在一个整体的全局级别的模式语言中。每个细小的过程在完成自己的过程中，又为整体做出了贡献，使自身投入到更大的过程中。它像一个生命体一样，不断改变，不断完善，不断进化。
brood 2004年06月29日
读后感（二）里面就是提到了“生长”的观点。建筑其实也是在生长的，尤其是一个群体建筑。
软件也是一样，只不过还有不少人没有意识到。
软件也是一样，只不过还有不少人没有意识到。
kotton8848 2004年06月29日
虽然对软件学习不好 。。。。。。
但是最简单的道理还是懂的
今天下午在图书馆看到了一本城市建设项目管理的书。。。。
里面的内容跟一些软件的工程具有很大的相似性。。。。
但是最简单的道理还是懂的
今天下午在图书馆看到了一本城市建设项目管理的书。。。。
里面的内容跟一些软件的工程具有很大的相似性。。。。
Chuanyan 2004年06月29日
本人没什么感情，体会不到那么多哲理……
rtdb 2004年06月29日
呵，不好意思，
自从我发现软件需要不断修改和变化才有生命力后，
我再也不把软件和建筑相提并论了。
我成了敏捷者，认为软件需要适应变化。
一个好的软件，必需是可进化的（重构）
自从我发现软件需要不断修改和变化才有生命力后，
我再也不把软件和建筑相提并论了。
我成了敏捷者，认为软件需要适应变化。
一个好的软件，必需是可进化的（重构）