Posted on 2005-12-20 23:25
非鱼 阅读(3204)
评论(6) 编辑 收藏 所属分类:
面向对象设计
软件架构师不是建筑架构师。他们之间除了名字,没有任何的共同之处。把软件架构师和建筑架构师类比,甚至把他们等同起来,是一种错误的观念。
建筑是实体的,软件是形式的。实体的建筑以结构为其主要内容,辅以少量动态的考虑(给水、排水及其他)。软件则是静态的结构和动态的行为的结合体。从这个
角度,建筑师的建模主要是静态的建模,比一个机械工程师,他多了蓝图的绘制的工作;而一个软件架构师不仅要对软件的结构进行建模,还要对软件的运行时刻的
行为建模。
建筑是一次性的,软件是演变的。虽然我们也说“旧城改造”,但那是拆了重建,而不是在原基础上改造。一栋造好的楼房,是不能在上面再增加一层的。软件则是
在原基础上修改,以满足用户需要。在这个前提下,建筑的架构是不会改变的;而软件在多次修改的情况下很可能触及架构上的变动。所以软件架构师必须在软件的
整个生命周期中时刻注意架构是否会变化,并且可能会主动调整它。
在建筑设计中,必须满足结构力学等基本原理,否则生产出来的建筑本身的使用质量没有保证,这是一个强制的要求,也存在相关标准。而软件在设计上只有一堆原
则,指导我们设计。即使你没有遵循这些原则,生产出来的产品一般也是可用的,具有使用质量,但产品改进的质量就难说了。因此软件的设计也比较难以把握,生
产一堆可用的垃圾的情况比较普遍。
建筑投资商往往给出一些量化的数据,建筑师把这些量化的数据转变成一个实际的建筑,在这个过程中一般不会有大的偏差。而软件尤其是应用软件,强烈依赖于用
户的需求。我们设计应用软件,基本上等同于对用户的行为进行建模,在目前对于人类行为的研究远远低于对于基础数学、物理学研究的情况下,一次成型的软件是
不可能存在的。应用软件的开发,基本可以描述为“在变化的基础上工作”。
在满足使用质量的前提下,建筑师极力追求建筑的外形。而软件也有这样做的(国产的一些网页,大家是否也觉得恶心呢?)。但一般用户在满足其开始的外在表现
的要求之后,慢慢就越来越关注软件的内容,关注软件是否真的帮助到了他们的生活,并且开始发起一次次的修改请求。
综上所述,软件架构师和建筑师的差别巨大,试图以建筑师的角度解释软件架构师,甚至想找到一个类似的解决之道,是不可行的。而对于初步接触架构师的人来
说,总是把架构师和建筑师对比也很容易误导他们。类比固然可以帮助理解,但也可能造成误解。
从另一个角度考虑,假设软件架构师和建筑师确实可以互通,那么如果存在一个既是软件架构师又是建筑师的人,他就可以领导软件产业一往无前
了。可是这么多年来,为什么没有这样一个人呢?
评论
# re: 架构师不是建筑师 回复 更多评论
2005-12-21 08:44 by
不过感觉还是差不多,都是画图纸的。而我则是下面和泥砌砖的:)
# re: 架构师不是建筑师 回复 更多评论
2005-12-21 10:16 by
其实我一直有一个想法,将软件开发和建筑和机械等类比其实是不合适的,其实更应该和写作或者电影拍摄类比。
因为软件开发的产品,其实是人的思想的固化物,是对人类社会中的业务、规则、关系的描述、体现和抽象。所以做一个好的软件,其实就象拍一部好电影一样难,要有优秀的剧本/编剧(架构师),卓越的导演/制片(PM),最好还要天才的演员(开发人员)。
还没想好。。。。。。。
# re: 架构师不是建筑师 回复 更多评论
2005-12-21 12:38 by
关于架构师更像导演而不是建筑师的问题
可见《成功的软件项目管理-银弹方案》一书
爱尔兰作者费格斯在其中做了精彩的阐述
# re: 架构师不是建筑师 回复 更多评论
2005-12-22 11:44 by
我个人感觉还是,比较接近的。
之所以现今的软件架构与建筑架构有较大差异,主要是因为软件领域和建筑领域的发展阶段不同。一个几十年,一个上千年了。成熟度不一样。如果类比现今的软件领域和早期的建筑领域会发现很多共同点的。
# re: 架构师不是建筑师 回复 更多评论
2005-12-24 15:34 by
建筑是一次性的,软件是演变的。一个特定的建筑是一个时代的象征,它不仅不能变,人们还希望它能以老样子一直存在下去。我们的故宫,长城。总不能把故宫再利用成某某步行街,某某大卖场。软件的关键就在这个软字上了。考验你的真是软件的弹性上。
# re: 架构师不是建筑师 回复 更多评论
2006-06-02 11:34 by
软件架构师与建筑架构师可以类比,它们之间确有相通之处,类比来理解有好处;当然也有不同之处,等同起来肯定是错误的,也没人会真这样等同理解;也许类比会引起一些误解,只要澄清和避免就好了,你的观点不用这么极端。
该文提出的建筑与软件的不同点,体现在以下方面:
1)建筑主要是静态结构实体,软件是静态结构与动态行为的结合体。
2)建筑是一次性的,可扩展性不强,建筑完成后只需维护工作,可能千年以前的建筑至今没多大变化;软件是不断进化的,可扩展性强,在架构不变的情况下,还可以对其修补,添加插件增强功能,不断进行升级换代,最新版相比几年前的版本可能面目全非。
3)在标准上,软件缺乏建筑领域众多的质量标准,使得软件的质量保证较难检验。
4)在需求分析上,软件相比建筑较难实施。建筑的需求通常有定量的数据和规范的说明;软件尤其是应用软件,强烈依赖于用户个性化的需求。应用软件的需求分析基本上等同于对用户的行为进行建模。而用户行为常常缺乏严格的定义,没有清晰的描述,给软件的设计与开发增加了难度。
以上是不同点的总结。上述四点中,第一点反映了建筑与软件内在逻辑上的不同;第二点反映了两者在完成后的发展的不同;第三点反映了两者在质量保证标准上的不同;第四点反映了两者在需求分析上的不同。这些不同点是值得注意的地方,但在工程方法论上,软件可以从建筑领域中借鉴很多。
作者与该文观点相悖的是,对UI的追求,建筑和软件在理念上是一致的。在满足质量的前提下,为什么不能提供给使用者更友好更美观的外观呢。地球上众多经典建筑无不具有极具特色,饱含艺术性的特点;众多经典软件的界面也往往得到用户真心实意的赞美。我们要避免的是,不要金玉其外,败絮其中,要把软件功能的质量放在第一位,在高质量地实现软件功能的同时也追求最友好最优美的用户使用界面。
事实上,建筑与软件仍具有大量的相通之处,此处不一一赘述。读过《设计模式》的朋友可以发现,GOF从建筑领域得到了大量有益的启示。另外,建议大家读一下《建筑的永恒之道》,相信此书会带给你一些有益的思考。