多年以来,软件行业一直在使用一种类比,即以建筑来做参考和比喻。这种比较在软件语言里随处可见,比如架构(architecture)、地基(foundation)、建造者(constructor)、项目(project)、施工规范(building code)等。这些说法是如此之流行,以至于影响到了我们对软件开发的理解。不幸的是,这种比喻从根本上来说是不恰当的,它的缺陷已经把我们引向了一些错误的道路。
在建筑行业,很多重点都放在可预测性上——预先把需求确定清楚,并且缩减成本。这些都是成熟行业的标志。而当我们把这些重点应用到软件上时,问题就来了!
经验法则、施工规范和原材料
现代建筑可以追根溯源到几百甚至几千年以前——就看你把起点放在哪儿。经过所有历史的沉淀,大量的专业知识凝结在了经验法则里,比如:
在大部分地方,每平方英尺的建筑成本是一个众人皆知的常数。举个例子,我们最近在家里做了一些翻修,行业里的朋友就提醒我们说:在渥太华,典型的翻修成本在每平方英尺$35到$50之间。他们说得非常准!
对水泥楼板深度的一个比较好的评估是,相当于它的无支周长的1/180。
另一方面,软件最多也就70年的历史。它的经验法则还没有像建筑那般牢靠的历史,尚不足以保障坚不可摧的应用。
经验法则最终会被编写成施工规范而固化下来。造房子的时候,施工规范决定了从壁骨间距,到墙上和屋顶绝缘物数量的方方面面。这些规范意味着所有的房子都达到了最低要求标准,极大地提升了成本的可预测性。
这些施工规范的存在,主要是因为建筑材料(木头、钢铁等)和工具(铁锤、锯子等)的种类是有限的。这些材料的属性和故障模型都是可预见的。能与特定材料配合使用的工具为数不多,也已被充分认知。当然,在建筑行业,材料和工具也在持续进化,但其进化速度远远比不上软件。
在软件行业,跟上一系列新材料和工具的难度要大得多!编程语言、程序库、支持工具每年都会冒出来,并且不断进化。内容也在不断丰富。即使我们专注于现有的语言和库,为了制定标准规范而去探索所有的细节并且体会个中的细微差别,这也需要花上几年的功夫。
正是因为易懂、稳定的材料和工具,才有了制定建筑规范的可能。而软件世界的不稳定性,决定了我们在这个领域永远也不会有“施工规范”。
在软件行业不存在有用的经验法则或施工规范!
物理约束和稳定的需求
大楼、桥梁和其他建筑工事都受着物理约束的支配。依据使用的材料,这些约束决定了一个建筑物的尺寸、形状和用途。举例来说,木结构建筑受限于4~6层的高度;桥梁的跨度受限于使用的材料,以及这些材料相关的物理属性。
大楼和桥梁的建筑代表了一个问题域,已被人世代研究和试验。因此,客户需要问的问题都是可预见的,答案的范围也是有约束的。
建筑设计必须适应现场和功能的约束。想象一下,把办公楼建成围绕单点旋转的陀螺仪那样,尽管很有趣,但它在物理上不切实际,也无法满足功能上的需求。在修筑桥梁或公路时,依据需要承受的车辆类型和尺寸,都有清晰的标准去遵循。
而软件并不受制于类似的约束。如果客户真的想要一个陀螺仪那样的东西,我们很可能可以交付。我们需要支持的用户类型以及用途,与建筑比起来要宽泛得多!
大楼一旦开建,地基都打好了,你就不能轻易改变尺寸或现场位置。大楼的内部机构一旦开工建设,你就不能随意决定新增一个电梯井或者加一个侧翼。修建桥梁时,一旦桥墩浇筑好了,你就不能因为客户选错了地方而把它们移动20米。(好吧,你能,只不过在此之前的工作都白费了,你需要从头再来!)
而对于软件来说,我们几乎可以做我们想要的任何改动,简单也好,复杂也罢,比如把支持的用户数从100提高到1000,改变产品方向(Yelp原本只是一个向朋友推荐餐厅、医生等信息的工具。后来才演变成了一个评论网站),换一种编程语言(我曾经参与过从Java变到.NET又变回Java的项目)——所有这些变动比从头再来的成本要小得多!
译者注:Yelp是美国著名商户点评网站,创立于2004年,囊括各地餐馆、购物中心、酒店、旅游等领域的商户,用户可以在Yelp网站中给商户打分,提交评论,交流购物体验等。
正因为我们在软件上有极大的灵活性,我们也能够在开发的全过程中接受需求的改变。开发早期阶段被挖掘出来的需求,在它们被最终实现之前往往会变动好几次。
在建筑的世界里,设计师把一套设计图交给建筑工人的时候,还能有相当的信心他们可以正确理解。尽管还是会有一些关于变动的需求和沟通,但变动的程度不可与软件同日而语。反观软件世界,我们并没有有效的方式(即使是UML)来做到给开发者交付了设计图之后就可以甩手不管。取而代之的是,我们要在客户和软件开发者之间持续不断地进行一系列的会谈。
软件比建筑更倾向于接受大幅度的改动!
人员
在建筑行业,工人通常被认为是可以交换和替换的。存在这样的假设:在造一间房子的时候,如果你把木匠换掉,结果通常是一样的。
这在软件世界里可不是这么回事!因为工具(编程语言和库)和问题领域存在的复杂性以及变数,开发者、业务分析师、测试人员、用户体验设计师等人是不能随处流动的。
那些认为软件与建筑有关联的人想当然地以为,人员是可以替换和交换的。但那与事实相去甚远!软件的所有实质内容都是各团队里的人构建出来的,如果你把一个团队成员替换掉,这会在以下三个主要方面对团队带来影响:
他们会失去只有那位前团队成员才了解的知识;
他们必须培训新团队成员:他们在做什么,以及最新的进展;
他们必须花时间与新人建立起有效的工作关系。
结果是,替换或增加一个新人把整个团队的进度拖慢了至少3~4个月。从个案来看,新的团队成员在完全发挥效力之前常常花费比那更长的时间。尽管建筑行业在人员变动时也会遭受进度拖延的痛苦,但其痛苦程度是远远不及软件项目的。
Fred Brooks(《人月神话》的作者)有一句名言:“向进度落后的项目中增加人手,只会使进度更加落后。”40多年过去了,这句话仍然有效!
结论
那些经常用来描述软件的建筑隐喻是错误的。可悲的是,因为有了这层暗示,我们把很多重点放在了错误的地方:
力求把需求预先定义清楚,而不是接受:变化才是常态;
强调架构和架构师的重要性,而不是接受:软件是可适应的,可由团队里的任何人来改变;
假设人员是可替换的,并且时间问题可以通过增加人手来解决,而不是接受:每个人都是独特的;
追求可预测性,而不是接受:我们的领域还没有被很好地认知。
软件与建筑绝无关系!
我们不是在建造,而是在探索!
我们在客户的问题空间里探索。我们正在提出新的想法,而它们刚好用代码来表达。让我们丢弃老的建筑隐喻吧,因为它们会使我们通向未来之路的地基崩裂坍塌。持这个观点的人可不止我一个哦。
版权声明:感谢原作者的辛苦创作,原文:https://agilepainrelief.com/notesfromatooluser/2015/04/software-development-is-not-a-form-of-construction.html#.V0-i_JN94mo,转自:http://blog.csdn.net/happydeer/article/details/51536364,如转载涉及版权等问题,请与我们联系(公众号:数通畅联)将在第一时间处理,谢谢!
相关推荐
开发人员应具备良好的团队协作能力、沟通技巧、问题分析和逻辑思维能力,同时,书面和口头表达能力也是必不可少的素质。 软件需求分析是软件开发的关键阶段,它涉及理解用户的功能、性能、行为和设计约束期望。通过...
由于提供的文件信息不包含实际的内容,只有标题...通过学习书中如何将东方文化的哲学理念融入建筑设计的方法,并将这些方法类比到软件架构设计中,读者可以从中获得灵感,从而提升自己在软件开发和系统构建方面的能力。
软件开发与建筑施工的类比形象地展示了这一过程的复杂性和协作需求。从最初的用户概念到需求分析、设计、编码、测试,再到后期的维护,每个阶段都需要严谨的处理,因为软件开发的风险性极高,如果不进行科学管理,...
7. **问题整改**:建设行政主管部门对存在问题的整改要求,类比于软件开发中对bug修复和改进的需求。 8. **验收报告**:工程竣工验收报告与软件开发中的项目总结报告相似,包含项目概况、执行情况、评价和相关文档...
在当今这个数字化迅速发展的时代,软件开发项目如同建筑工程一样,需要经过周密的设计与计划来确保最终的产品能够满足需求并拥有良好的性能。本文将深入探讨如何将砖砌化粪池的施工方案设计类比为软件开发项目实施的...
20世纪50年代以来,软件成本逐渐攀升,占据了计算机系统成本的大部分,同时,软件开发进度的不可控性和质量问题日益凸显。软件开发不再是简单的编程任务,而是智力密集型的工作,需求变更频繁,盲目增加人力反而可能...
5. **源码软件**:虽然这个标签与传统意义上的IT源码软件不符,但我们可以理解为设计过程中可能使用的计算机辅助设计(CAD)软件或结构分析软件,如AutoCAD、Revit、ETABS等,这些工具在现代建筑设计中不可或缺。...
尽管与软件开发领域直接的关联性不强,但项目管理和监控的原则在两个领域间具有显著的相似性。因此,我们可以从分布式屋顶光伏发电项目的监造方案中抽象出一些管理理念,并将其类比应用到软件项目的质量管理中。 ...
**施工条件及施工准备**:这部分虽然主要是针对建筑项目的,但可以类比为软件开发的基础设施准备,如开发环境的设置、工具的选择、通信和协作平台的建立,以及技术文档的准备。 在软件开发中,类似的步骤包括: 1. ...
在IT项目中,这可以类比为考虑软件开发对环境(如能源消耗、电子废物)的影响,并采取绿色IT实践,例如采用能效高的硬件,优化代码以减少计算资源消耗,或者选择可回收的设备。 虽然这个解释将建筑工程领域的概念...
本文将详细解析沙洋县卷桥河综合治理工程中地基验槽记录的实际应用,并将其与软件开发中的项目管理过程作类比,以加深理解。 沙洋县卷桥河综合治理工程的地基验槽记录涉及对多个基坑开挖情况的详细描述。每个基坑的...
通过将软件开发过程与日常生活中的事物相比较,如将软件系统比喻成建筑、将软件错误比喻成“臭虫”等,可以使抽象的编程概念变得更加直观易懂。隐喻的应用不仅限于简单的命名,还包含了对类比事物之间深入的体验与...
软件结构方面,我们可以类比建筑结构。比如,较低层的楼房一般采用砖混结构,而高层和小高层建筑通常采用框架结构,且楼层越高对结构的要求也越高。同样,对于软件系统而言,系统越大、生命周期越长,结构的重要性就...
软件架构是软件开发中不可或缺的一部分,它对于确保软件系统的质量、可维护性和扩展性至关重要。通过深入理解软件架构的基本概念、要素以及其在软件开发周期中的作用,可以更好地应对日益复杂的软件开发挑战。随着...
通过理解这些原则并应用到实际的软件开发中,可以创建出高效、可维护且适应性强的软件体系结构。 总结来说,Grady Booch的PPT揭示了软件体系结构的重要性,它是软件开发成功的关键。从简单的项目到复杂的系统,都...
故事一提到的“俯卧撑”的大楼,强调了建筑物的基础和结构对其稳定性的决定性影响,类比到软件开发中,意味着系统的基础架构必须牢固,才能支撑其功能的实现。故事二,塔科马海峡大桥的倒塌,揭示了未经验证的新颖...
建筑行业的类比显示,软件开发与建造建筑物不同,前者无法在初期就确定所有细节,更需要灵活应对。 **传统方法的缺陷** 传统开发方式的问题在于,需求变更频繁,且在项目后期更改成本高;客户往往不能准确表达需求...
机械设备配置是建筑工程中另一个不可忽视的部分。合适的机械使用可以极大提高施工效率。在IT项目中,这可以类比为对硬件设备、服务器、网络设备的采购与配置,以及开发和测试用软件工具的选择与使用。保持设备的高效...
对于大型项目而言,统一的建模语言更是不可或缺的,它能够帮助开发团队有效地沟通、协作,并在整个开发周期内保持一致性。 ### 结论 UML作为一种广泛接受的建模语言,为软件开发提供了统一的标准和工具。通过学习...
- 想象一下建造一座现代高层建筑,这类似于在软件开发中使用分层架构设计模式。该模式允许每个软件层,如数据层、服务层和表示层,支持无缝交互,同时保持独立性,增强可维护性和可扩展性。就像一座建筑被分为基础...