程序员可以从建筑业中学到什么？[关闭]

在与同事讨论软件设计和开发原理时，我注意到类比的最常见来源之一是建筑行业。我们构建软件，并将设计和结构视为体系结构。

学习（或教导）的最佳方法之一是通过分析类比- 从构造中还能得出哪些其他类比？ （是否已经在软件中普遍使用）。

请提供有关编程概念与构造概念的相似之处的描述或您的个人经验。

^{[ 取材于艺术和人文科学的编程概念学分]}

那就是设计模式的来源。

据称是向世界介绍这一概念的人是克里斯托弗·亚历山大（Christopher Alexander），他在1977年的著作《一种模式语言：城镇，建筑物，建筑》中。从那里，四人帮（GoF）捡起它，剩下的就是历史了。

即使在现在，在演讲中以及在软件开发和体系结构书籍中，建筑界与软件开发界之间的类比仍然盛行。

我可以想到或回忆的一些类比和参考：

• 例如，在建筑物的建造过程中改变要求可能对客户来说变得更加荒谬，例如：“哦，我想要一个车库，而不是刚装修好的厨房在哪里”。
• 临时辅助材料，例如脚手架（在建筑世界中意为| 软件开发）
• 客户不能不增加成本就继续添加功能，很多时候他们想免费完成工作，有时我们愚蠢到无法接受。这在建筑世界中是不可能发生的（请参阅需求蠕变）。
• 软件开发中的角色：架构师是解决方案设计的核心；顾问和承包商可以互换使用；工人是程序员。
• 在两种情况下，客户都无法提供准确的要求。
• 预算和时间估计通常是错误的。
• 直到最后，才能真正看到其产品的真实形式。
• 建筑物在建造后可能会出现建筑故障，就像软件中的错误一样。
• 如果产品做得不好，有时最好将其拆除并重新开始，而不是修复它。
• 客户不知道质量差的工作的实际和实际结果，而是想要最便宜的解决方案。
• 开源。我只是在看Doc Searls的演讲“ 为什么所有业务都将基于开源 ”，他讲的是建筑社区如何共享技术和常识，而不是像开源社区一样向他们申请专利，即使建筑物中有些东西包含内置的专有产品。
• 如果客户积极参与，项目对每个人都会更好。

（如果想到更多，我将添加它们。）

有些人认为一般类比是正确的，为此推荐阅读“软件构造类比被打破”。此外，SO上有一个与此相关的问题，即软件与建筑之间的类比是什么问题？。

在整个软件开发的历史中，我们从建筑业中吸取了很多话语和想法，实际上，我们可能吸收了很多东西，我认为没有什么可采取的了。

我们进行了整个过程：让客户制定规格，然后由建筑师规划，然后由工程师设计，最后为从建筑行业实施的猴子编写代码，结果完全被误导了。

这是因为当您盖房时，如果您的地基不对，您就会感到无所适从。认真的。抬高建筑物并替换其地基要比报废整个建筑并重新开始花费更多。但是在软件中这是完全可能的。我将客户端软件重新制作为客户端-服务器解决方案，而用户没有注意到任何事情，只是将调制解调器移至服务器机房。这就像居民睡觉时用船代替混凝土基础。

软件是不一样的结构。这就是为什么整个软件行业在顽皮开始的时候就打开了，而运行项目的整个“瀑布”过程在短短几年内就被敏捷过程所取代。

至于言语，很多是正确的，也可能是错误的。

框架是尚未采用的最明显的框架。并且有管道。

我已经使用了这个比喻...许多软件项目开始了，因为需要一些软件的人都知道一个“杂工”，而他们雇用这个人来为他们建造一个相当于花园大棚的软件。这是一个很小的，有用的小应用程序，可以很好地完成工作。

然后，客户返回杂工，对他们的工作感到满意，并要求他们更换软件以完成另一件事。很多时候，这项新功能与最初的要求没有太大关系，因此几乎就像他们要您在带独立入口的花园棚后面建另一个房间一样。

然后他们想在棚子里放一盏灯，这样他们就可以让杂工回来了，他从房子的主面板开了一条电路，在每个房间的天花板上安装了一个拉链灯开关，并将它们连接到电路上。 。

然后，客户决定要使用一些电动工具，但是它却使断路器不断工作，因此他们打电话给该人员，实际上，他必须撕掉他跑到主板上的单个电路，并安装一个更大的导线和一个棚子面板。他必须将电线敷设两次，并支付两个电气许可费等。这效率很低。

然后客户要求一些荒唐的东西：您能把我的花园棚变成车库吗？我不希望您再做任何您想做的事情……我只是希望您将它做大一些，以便可以将我的车停在那里。然后，在很多情况下，杂工会认为“顾客永远是对的”，然后继续在棚的3个侧面上增加附加物，使其变大，撞倒隔板之间的墙等。当然，屋顶末端下垂，因为构造不正确等。

因此，客户不再对此印象深刻，但他们仍然想要更多。他们要求打杂工一遍又一遍地添加一个房间，或更改此现有房间以执行此操作，依此类推。最终，您得到的东西看起来像The Burrow，而且在结构上听起来很合理。

现在，大多数人还不够傻，无法在构造世界中尝试这种方法，但是这种情况在软件世界中一直存在，因为人们没有建立以下联系：

1. 有资格建造一个真正漂亮的花园棚屋的人不一定有资格建造房屋。

2. 如果您提前知道要分阶段建造房屋，但只是从花园棚开始，那您会做不同的事情，花园棚的成本会高得多（您会倒掉非常厚的垫子，请确保您使用的导体足够大，足以满满完成房屋等的负荷。）

3. 在很多情况下，从一个阶段升级到另一个阶段涉及撤消以前完成的许多工作，从而使它比看起来应有的价格昂贵。

4. 在建筑世界中，我们可以为客户提供一个好主意，即在设计阶段结果会是什么样子，但是在软件世界中我们没有这种能力。如果到那时，您基本上已经编写了该软件的很大一部分。

敏捷宣言是承认软件/构造类比已损坏的结果。诸如自动化单元测试和迭代发布周期之类的东西在构造上是并行的。这些东西利用了从设计到原型（我们称其为编译或构建）几乎为零的成本。

该条款完成的工作，并修剪浮现在脑海中。

当主要的结构决策完成时，可以考虑一些美学选择是可以的。

一句老话：量两次，切一次。

编辑： Atul Gawande的“清单宣言”中 有一节讨论管理大型建筑工作。当他们到达一个非常复杂的地步时，他们会与相关专家开会，重新讨论问题，并查看项目中是否发生了任何人都应该知道的事情。我们可能无法提前计划它们。

构造和编程都存在局限性。

如果您作为客户不能提出如此荒唐的要求，那就是将完成的酒店建筑延长至一个周末，然后将机场置于地下层和顶层公寓的跑道中，为什么您不能接受并非所有的调整都针对完成的酒店软件有可能吗？它不是0和1的魔球，它是一个复杂的结构，虽然不重要，但也有其局限性。

我在整个学校从事建筑工作，在有些地方甚至没有类比，适用相同的概念。但是通常，比较的诱惑太过分了。

当我对一份工作进行估算时，我知道关于完成某项工作需要花费多长时间的平均数。例如，对于制造店面窗户，我们只是简单地计算了计划中框架中的接缝数量，并且很好地知道了要花多长时间。就像编程一样，我们必须按计划考虑变量，尽管这可能会使您丧命。例如：让水暖工出现，发现停车场已经铺好，由于沥青热，他们无法进入建筑物，这是相当昂贵的。

但是，施工具有数千年的经验可以借鉴。贸易的基本规则是由一贯的物理定律所驱动。风荷载和静荷载的计算与使用滑尺进行计算时相同。工具和技术的改进已经到来，但与我们所经历的相比却步履蹒跚。

另一方面，我们仍然发现我们的许多模式和实践都需要改进的空间。Singleton曾经是一个好主意，现在大多数考虑它的人都喜欢IoC / DI模式。

我们还缺乏有效的许可和认证。在许多地区，即使只是成为修理工，更不用说安装工人了，水管工必须获得许可或在有人的监督下工作。要获得该许可证，需要在现场工作一定时间。我并不是在支持或反对许可，只是指出这一点，因为这是一个巨大的差异。

当然，在这两个领域中，架构师都可以绘制无法实现的内容。

脚手架，“一种临时结构，用于在建筑或维修建筑物及其他大型结构时支撑人员和材料。” ^{[来自维基百科的定义]}

该概念之所以起作用，是因为能够快速创建编程中的脚手架并提供临时功能，直到真正的结构就位。

我知道有些建筑公司会以最低的投标价进行耕种，做些草率的工作，推卸应承担的保修义务，着眼于日期而不是质量，然后对“制成品”收取可笑的利润。

但是我认为程序员或咨询机构没有从这些实践中学到任何东西。

虫子最终会变得像地狱般昂贵，甚至杀死人？

对于任何学科的复杂工程项目，都有一些基本准则：

1. 计划，蓝图，设计等的重要性，
2. 基础数学的重要性
3. 重用其他类似项目的想法/经验
4. 使用别人建造的现成的积木/组件
5. 在生命周期的早期就纠正问题，
   等等，

体系结构，土木和软件工程学科之间的共性似乎主要是由于缺少装配线：每个项目都具有自己的独特性。

随着时间的推移

但是在建筑行业，工人得到加班费。

使用标准，约定和预建组件。您不太可能遇到这种问题。

我在市场上找不到适合我们定制插座的任何产品。

当您只有一把锤子时，一切看起来都像钉子。:)

反复劳损

在两个行业中，它们都是职业危害，必须采取预防措施来预防它们。一旦开始，就很难治愈。