原文链接
作者:Mark Levison

多年以来,软件行业一直在使用一种类比,即以建筑来做参考和比喻。这种比较在软件语言里随处可见,比如架构(architecture)、地基(foundation)、建造者(constructor)、项目(project)、施工规范(building code)等。这些说法是如此之流行,以至于影响到了我们对软件开发的理解。不幸的是,这种比喻从根本上来说是不恰当的,它的缺陷已经把我们引向了一些错误的道路。

在建筑行业,很多重点都放在可预测性上——预先把需求确定清楚,并且缩减成本。这些都是成熟行业的标志。而当我们把这些重点应用到软件上时,问题就来了!

经验法则、施工规范和原材料

现代建筑可以追根溯源到几百甚至几千年以前——就看你把起点放在哪儿。经过所有历史的沉淀,大量的专业知识凝结在了经验法则里,比如:

l  在大部分地方,每平方英尺的建筑成本是一个众人皆知的常数。举个例子,我们最近在家里做了一些翻修,行业里的朋友就提醒我们说:在渥太华,典型的翻修成本在每平方英尺$35到$50之间。他们说得非常准!

l  对水泥楼板深度的一个比较好的评估是,相当于它的无支周长的1/180。

另一方面,软件最多也就70年的历史。它的经验法则还没有像建筑那般牢靠的历史,尚不足以保障坚不可摧的应用。

经验法则最终会被编写成施工规范而固化下来。造房子的时候,施工规范决定了从壁骨间距,到墙上和屋顶绝缘物数量的方方面面。这些规范意味着所有的房子都达到了最低要求标准,极大地提升了成本的可预测性。

这些施工规范的存在,主要是因为建筑材料(木头、钢铁等)和工具(铁锤、锯子等)的种类是有限的。这些材料的属性和故障模型都是可预见的。能与特定材料配合使用的工具为数不多,也已被充分认知。当然,在建筑行业,材料和工具也在持续进化,但其进化速度远远比不上软件。

在软件行业,跟上一系列新材料和工具的难度要大得多!编程语言、程序库、支持工具每年都会冒出来,并且不断进化。内容也在不断丰富。即使我们专注于现有的语言和库,为了制定标准规范而去探索所有的细节并且体会个中的细微差别,这也需要花上几年的功夫。

正是因为易懂、稳定的材料和工具,才有了制定建筑规范的可能。而软件世界的不稳定性,决定了我们在这个领域永远也不会有“施工规范”。

在软件行业不存在有用的经验法则或施工规范!

物理约束和稳定的需求

大楼、桥梁和其他建筑工事都受着物理约束的支配。依据使用的材料,这些约束决定了一个建筑物的尺寸、形状和用途。举例来说,木结构建筑受限于4~6层的高度;桥梁的跨度受限于使用的材料,以及这些材料相关的物理属性。

大楼和桥梁的建筑代表了一个问题域,已被人世代研究和试验。因此,客户需要问的问题都是可预见的,答案的范围也是有约束的。

建筑设计必须适应现场和功能的约束。想象一下,把办公楼建成围绕单点旋转的陀螺仪那样,尽管很有趣,但它在物理上不切实际,也无法满足功能上的需求。在修筑桥梁或公路时,依据需要承受的车辆类型和尺寸,都有清晰的标准去遵循。

而软件并不受制于类似的约束。如果客户真的想要一个陀螺仪那样的东西,我们很可能可以交付。我们需要支持的用户类型以及用途,与建筑比起来要宽泛得多!

大楼一旦开建,地基都打好了,你就不能轻易改变尺寸或现场位置。大楼的内部机构一旦开工建设,你就不能随意决定新增一个电梯井或者加一个侧翼。修建桥梁时,一旦桥墩浇筑好了,你就不能因为客户选错了地方而把它们移动20米。(好吧,你能,只不过在此之前的工作都白费了,你需要从头再来!)

而对于软件来说,我们几乎可以做我们想要的任何改动,简单也好,复杂也罢,比如把支持的用户数从100提高到1000,改变产品方向(Yelp原本只是一个向朋友推荐餐厅、医生等信息的工具。后来才演变成了一个评论网站),换一种编程语言(我曾经参与过从Java变到.NET又变回Java的项目)——所有这些变动比从头再来的成本要小得多!

译者注:Yelp是美国著名商户点评网站,创立于2004年,囊括各地餐馆、购物中心、酒店、旅游等领域的商户,用户可以在Yelp网站中给商户打分,提交评论,交流购物体验等。

正因为我们在软件上有极大的灵活性,我们也能够在开发的全过程中接受需求的改变。开发早期阶段被挖掘出来的需求,在它们被最终实现之前往往会变动好几次。

在建筑的世界里,设计师把一套设计图交给建筑工人的时候,还能有相当的信心他们可以正确理解。尽管还是会有一些关于变动的需求和沟通,但变动的程度不可与软件同日而语。反观软件世界,我们并没有有效的方式(即使是UML)来做到给开发者交付了设计图之后就可以甩手不管。取而代之的是,我们要在客户和软件开发者之间持续不断地进行一系列的会谈。

软件比建筑更倾向于接受大幅度的改动!

人员

在建筑行业,工人通常被认为是可以交换和替换的。存在这样的假设:在造一间房子的时候,如果你把木匠换掉,结果通常是一样的。

这在软件世界里可不是这么回事!因为工具(编程语言和库)和问题领域存在的复杂性以及变数,开发者、业务分析师、测试人员、用户体验设计师等人是不能随处流动的。

那些认为软件与建筑有关联的人想当然地以为,人员是可以替换和交换的。但那与事实相去甚远!软件的所有实质内容都是各团队里的人构建出来的,如果你把一个团队成员替换掉,这会在以下三个主要方面对团队带来影响:

l  他们会失去只有那位前团队成员才了解的知识;

l  他们必须培训新团队成员:他们在做什么,以及最新的进展;

l  他们必须花时间与新人建立起有效的工作关系。

结果是,替换或增加一个新人把整个团队的进度拖慢了至少3~4个月。从个案来看,新的团队成员在完全发挥效力之前常常花费比那更长的时间。尽管建筑行业在人员变动时也会遭受进度拖延的痛苦,但其痛苦程度是远远不及软件项目的。

Fred Brooks(《人月神话》的作者)有一句名言:“向进度落后的项目中增加人手,只会使进度更加落后。”40多年过去了,这句话仍然有效!

结论

那些经常用来描述软件的建筑隐喻是错误的。可悲的是,因为有了这层暗示,我们把很多重点放在了错误的地方:

l  力求把需求预先定义清楚,而不是接受:变化才是常态;

l  强调架构和架构师的重要性,而不是接受:软件是可适应的,可由团队里的任何人来改变;

l  假设人员是可替换的,并且时间问题可以通过增加人手来解决,而不是接受:每个人都是独特的;

l  追求可预测性,而不是接受:我们的领域还没有被很好地认知。

软件与建筑绝无关系!

我们不是在建造,而是在探索!

我们在客户的问题空间里探索。我们正在提出新的想法,而它们刚好用代码来表达。让我们丢弃老的建筑隐喻吧,因为它们会使我们通向未来之路的地基崩裂坍塌。持这个观点的人可不止我一个哦!

软件开发不可与建筑类比相关推荐

  1. CAD制图, 机械CAD, 建筑CAD, 电力CAD, CAD设计, 数控与CAM, DXF导入\导出, 打印, 软件开发, VC++源代码,OCX 控件源程序2018

    CAD制图, 机械CAD, 建筑CAD, 电力CAD, CAD设计, 数控与CAM, DXF导入\导出, 打印, 软件开发,VC++源代码,OCX 控件源程序2018 -- 100%源码开放企业级CA ...

  2. CAD制图,机械CAD,建筑CAD,电力CAD,CAD设计, CAD标注, 打印, 软件开发 ,VC++源代码,VB 控件源程序...

    CAD制图,机械CAD,建筑CAD,电力CAD,CAD设计, CAD标注, 打印, 软件开发 ,VC++源代码,VB 控件源程序 E-Form++可视化组件库集成最新最尖端的图形处理技术,全部采用VC ...

  3. 软件开发随笔系列二——关于架构和模型

    软件开发随笔系列二--关于架构和模型 文章目录 软件开发随笔系列二--关于架构和模型 软件模型 功能模型 概念层 边界 参与方 分组分类 逻辑层 功能组织图 层次.模块化 接口 流程模型 概念层 业务 ...

  4. 工作中使用到的单词(软件开发)_2023_0316备份

    原文: 工作中使用到的单词(软件开发)_http://42.62.43.136:8081/_sun0322的博客-CSDN博客 目录 ■Java学习汇总 ■常用链接 ■2020/03/15  (最初整 ...

  5. 如何向外行人介绍软件开发

    经常被问到一个问题,你是从事什么职业的?我会说我是从事软件开发的,也就是程序员.对方如果不懂软件开发,那么也就哦一声就过去了.因此,也就产生了一个念头,如何向别人介绍软件开发呢? 软件开发的百度定义是 ...

  6. 软件开发架构模式浅谈:一些思考和实践记录

    一 背景和问题 我个人平时会比较慎用"架构"这个词 一方面是觉得业界有很多架构大师和架构模式,而我的认知和实践有限: 另一方面是因为这个词看着挺高大上.有点务虚,如果不结合实际场景 ...

  7. 瀑布模型:像工厂流水线一样把软件开发分层化

    今天我们聊一聊这个软件工程中的瀑布模型. 瀑布模型算是现代软件工程的起源,软件工程的发展,很大部分都是构建于瀑布模型的基础之上的.我们后面所学的软件工程的很多内容,都是源自瀑布模型的衍生,或者其中某个 ...

  8. 浅谈软件开发架构模式

    本文作者将介绍他对于软件开发架构模式的一些思考和实践. 背景和问题 我个人平时会比较慎用"架构"这个词 一方面是觉得业界有很多架构大师和架构模式,而我的认知和实践有限: 另一方面是 ...

  9. 软件开发向大数据开发过渡_如果您是过渡到数据科学的开发人员,那么这里是您的最佳资源...

    软件开发向大数据开发过渡 by Cecelia Shao 邵Ce It seems like everyone wants to be a data scientist these days - fr ...

最新文章

  1. java struts2 session mysql 内存不足_Java - 用户在线的数据库实现方法和内存实现方法...
  2. Go 读取 yaml 文件并解析
  3. html5+css3基础教程收集
  4. python 文件指定位置写入-Python从文件中读取指定的行以及在文件指定位置写入...
  5. AnalyticDB for MySQL:PB级云数仓核心技术和场景解析
  6. nginx 80端口重定向到443端口
  7. OAuth 及 移动端鉴权调研
  8. oracle 表查询(二)
  9. VMware与 Device/Credential Guard 不兼容.
  10. android 按钮复用,Android Button 自带阴影效果另一种解决办法
  11. java 解析mp4文件头_视频文件头解析--MP4-获取mp4 文件信息
  12. 2021SC@SDUSC 量子加密库libqs
  13. php 批量生成一维码,thinkphp5 + barcode 生成条形码
  14. NCA:九岁的已经发起了 DDoS 攻击
  15. 洛谷P1725 琪露诺 题解
  16. 达内java月考_达内java5.第二次月考(附答案)..doc
  17. mysql更改数据库登录密码失败;Access denied for user 'root'@'localhost;mysqladmin: connect to server at 'localhos
  18. 选择率,基数计算公式
  19. Java百度识别身份证照片、驾驶证识别
  20. android app排行榜 易观智库,易观发布4月移动App月活增幅排行榜

热门文章

  1. vc 实时显示系统时间
  2. IDEA中maven项目右边Dependencies报错飘红
  3. CSDN大会后参观微软亚洲研究院
  4. 单片机播放WAV格式音频的理解
  5. ngram语言模型—基于KneserNey及Modified Kneser Ney平滑
  6. 【visual studio】错误LNK 1168,无法打开 XXX.exe进行写入解决方案
  7. 一个毕业6年的程序员工作经历和成长感悟
  8. meta-data 占位符的引用
  9. 数字经济背景下的多元化转型,电信运营商如何突围?
  10. IT痴汉的工作现状33-HTML5的春天是原生App的冬天?