多年以来，软件行业一直在使用一种类比，即以建筑行业来做参考和比喻。这种比较在软件语言里随处可见，比如架构（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多年过去了，这句话仍然有效！ 结论 那些经常用来描述软件的建筑隐喻是错误的。可悲的是，因为有了这层暗示，我们把很多重点放在了错误的地方：
- 力求把需求预先定义清楚，而不是接受：变化才是常态；
- 强调架构和架构师的重要性，而不是接受：软件是可适应的，可由团队里的任何人来改变；
- 假设人员是可替换的，并且时间问题可以通过增加人手来解决，而不是接受：每个人都是独特的；
- 追求可预测性，而不是接受：我们的领域还没有被很好地认知。
软件与建筑绝无关系！ 我们不是在建造，而是在探索！ 我们在客户的问题空间里探索。我们正在提出新的想法，而它们刚好用代码来表达。让我们丢弃老的建筑隐喻吧，因为它们会使我们通向未来之路的地基崩裂坍塌。持这个观点的人可不止我一个哦！
