建筑与软件

从一开始接触软件设计，从四人帮的《设计模式》中获知很多的软件设计模式来源于建筑领域，《设计模式》的灵感来源于亚历山大的《建筑的永恒之道》。随着工作经历的增加，接触到了软件项目管理、软件项目组织架构、软件开发生命周期、软件合作模式等更多方面的知识。对软件领域这些方面知识的接触，让我惊讶的发现，这些软件知识很多都脱胎于建筑领域。软件工程与建筑工程都作为典型的工程建设，从工程本质来讲是相通和相连的，两者的方法论在一定程度上都是可以相互转化的，不管你信不信，反正我是信了。
    建筑领域的瀑布模型：建设大楼时，先客户方提出需求，交由设计机构负责设计出大楼的具体设计图样，交给施工方建造大楼，最后由客户方进行验收，验收通过项目就完成了，这是典型的瀑布模型。而现在房地产商在卖楼时提供的成品模型，也具有原型开发模型的韵味。在建筑领域有完全独立的设计机构、项目承包方和子承包方，其中设计机构映射到软件领域的分析设计团队，子承包方映射到软件领域的外包厂商。建筑领域有造价预算和实施计划，软件领域有工时估算和实施计划。软件架构中的UI层与现代建筑中不断变换的外部装修相切合，比如现在使用玻璃来作为墙体，这与软件领域中出现的越来越多的渠道界面何其相似。测试驱动的开发模式灵感来自于建筑工人在砌墙时，先拉圆锥线对齐，然后按照圆锥线来砌墙，以保持墙体笔直不弯曲。软件领域的很多设计模式来源于建筑领域的一些设计模式，比如facade模式就来源于以前的城门建筑模式，一个城只有1个城门供日常进出。软件领域中的组件化思想和建筑领域的预制件思想类似，门、窗等都是组件化理念。
    建筑学源远流长，经历了这么多年月的积累和发展，其中的思想和方法必然有很多值得软件学借鉴和学习的，从事软件业的朋友们有空或达到瓶颈时也不妨去翻翻建筑方面的书籍，学学建筑方面的知识，或许会有意想不到的收获。

出处：http://dryr.blog.163.com/blog/static/582110132011101491833885/

//---------------

杂感 ： 软件与建筑的异同


想谈谈自己对软件的一点看法，尽管有人说不要一说软件，就扯到建筑上面去，
可是我我还是觉得他们两个之间有很多异曲同工之处，

在设计阶段两者差不多，都是设计比开发要时间长，
而且设计占有举足轻重的地位，如果设计错误，那末即使开发时用的材料再好，也没有用，
而且后期维护很艰难，想想如果你要在的房间里装一堵墙，那还好说点，可是如果你要拆一堵墙，
真的不是那末容易，更何况如果拆一堵的话，还没有什莫效果，往往要达到效果要拆好几面墙，
这莫拆来拆去的，到最后觉得还是重新盖一间屋子好了。

回顾软件发展的历程从面向过程到面向对象再到面向组件，个人感觉还是建筑的理论发展得快，
德国建筑业在20年前就开始了组件的应用，就像搭积木那样建楼房，可是你去德国看看觉得好像不是用这种组件建造的房子也到处都是啊，
那也就是这些都是些20年前的建筑了，不仅是20年前，好多房子都是几十年上百年的历史了，
不像中国，拆了又建，建了又拆，到处都是5年以内的新房子。

可是软件的组件理论是近几年才开始应用的，典型的就是j2ee了，个人认为它的那种分而治之的思想很好，
对于大的复杂的东西，只能这莫解决了，j2ee 当然也有缺点，就是想一个人学个什莫东西吧，想把环境弄好都不很容易。

不过软件和建筑最大的区别就在于，
建筑设计师不必当过泥瓦工，他们把房子做成模型，或是画成设计图纸或是现在的用
3D的动画给演示出来，都能达到很好的效果可是一个软件设计师绝对不能没写过几行代码，
原因是因为，建筑设计师是一层抽象，就是把在现实世界中存在的东西，抽象出来，
可是软件是两层抽象，软件本身是抽象的，即使是客户能很清楚地描述他们的需求，
软件设计师也不能确定这个软件会是个什莫样子，所以在抽象的基础上再进行抽象的设计，
这莫一来设计东西和最后的软件成品差别就很大，以至到后来软件说明书里面的大部分定义都成了一纸空文，
没有起到它原来的作用。

还有我觉得，因为软件这个行业很热门，以至于好多人都来学，然后有些人对它没有兴趣，而又不得不在干着，
当然，他们会越干越觉的难受，好多人发牢骚，什莫太累了， 加班加点，因为熬夜而不得抽烟喝浓茶喝咖啡，
我觉得这都是他们自己选择的结果，爱因斯坦曾说过一句话（听老师说的，没有自己证实过），最简单的方法是最好的解决办法，但是也不能过于简单，
说的意思就是什莫事情都有一种优美的解决办法，好多时候，人们凭着自己的惯性思维，已经对面对常见的情况几乎不加思考的做下去了。
其实我们自己是可以选择的，好多人会说，你不在我这个环境下，你不知道，我们有多辛苦，我只能说，也许。

还有就是建筑界有所谓的炒家，把房子炒的很高，软件行业也有，
我不是说不希望，厂家宣传他们的东西他们的技术，而是不喜欢那种，是非颠倒，打击对手，没有凭据的乱说话，
一方面误导一些没有这方面知识的人，一方面让人觉得乱哄哄的，好像做实事的没几个，都在那里哗众取宠，
不过台湾到有几个是出的书多，人也挺有涵养的，而且他们共同的特点就是文学水平都很高，我想可能这也是学好
软件设计精髓的一个必要条件吧。

出处：http://blog.csdn.net/ridrare/article/details/1354013

//--------

建筑学的隐喻在软件业中一直很流行。开发软件和建筑楼房从某种意义上说都是一种构造过程，而建筑学的成熟无疑让很多软件工程师非常羡慕。Design Pattern的始作俑者坦承受到建筑学著作的影响更是让一些人对建筑学的精深顶礼膜拜不已。不过，建筑决不只是表面上的形象/功能设计，也决不是民工就可以干的活计，在现代建筑设计背后是土木工程的蓬勃发展。正是框架结构的出现和材料工艺的进步才使得批量生产的大型现代建筑成为可能。
        虽然建筑学有着它不为人知的复杂性的一面，但是与软件开发相比，它也有着简单贫瘠的一面。现在架构师言必称设计模式，但是估计很少有人读过Christopher Alexander的原著"A Pattern Language"。在Alexander的概念中，所谓的模式"describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". 关键在于这些模式在建筑学中往往映射为某种独立的原子化的实体(entity), 因此可以把它们作为一种语言的基础组分，构成所谓的Pattern Language. 例如现在要开发一个门廊，你可以从"私家的沿街露台(140)"开始，在"有阳光的地方(161)"做成一个"有围合的户外小空间(163)", 选择"6英尺深的阳台(167)", 保留"小路和标志物(120)", 注意"天花高度变化(190)"和"角柱(212)"的位置，在"各式座椅(251)"的旁边安排一个"高花台(245)". Alexander共定义了253个模式，括号中的便是模式的编号。很明显，物理空间的不可重入性直接规范了建筑设计空间的有限性。
       在软件设计中，类似VB/Delphi的可视化界面设计的操作过程与此类似：理想情况下界面开发基本就是用各种界面元素填满一个Form的过程。但是软件的一个本质复杂性在于它的基本结构单元是函数，而设计空间中同一个功能点对应的实现函数的个数和形式并不存在有限性的约束，函数的组合形式也不是线性延展的。建筑基本上依赖的是静力学，而软件无疑需要用动力学来刻画。即使是界面开发，我们所关注的也决不仅仅是静态摆放问题，而更重要的往往是界面元素动态相关和动态变化的问题。
       在Web开发领域，一直有人鼓吹模仿VB/Delphi的快速开发工具，但是我并不认为这其中的设计哲学是与软件的本质相匹配的。软件中所蕴含的无限的动态变化不应该仅仅通过有限的配置过程来应对，我们需要更加强大的结构抽象和结构构建手段。

出处：http://canonical.iteye.com/blog/122438

//-------

笔者：

在高中的时候，自己还能画点不错的素描，没有导者指点，就是按照实物的外形和颜色，及小学时学过的课程知识，描摹一些小的实物。那时的自己还能画出一些比较优秀的素描作品。那时觉得自己至少在空间构造上应该有点天赋，就希望自己考大学时，能够选择一个建筑师的专业读一读。可是造物弄人，自己报考了物理与电子信息专业，本来是通信相关的专业。后来发现软件可以解决的问题更多，硬件是机体，软件是灵魂，遂转入软件行业。之后就开启了软件开发之路，一路的学习，不曾停止，学习各个体系，学习各种编程语言。

上面介绍了自己选择软件之路的过程，今年时候读《HeadFirst 设计模式》 看到了亲切和伟大的“四人组”（GoF）。同样从书中看到了亚历山大的相关故事，这就开启了软件工程和建筑的相关性的思考。