为什么有些程序员认为理论与实践之间存在差异？[关闭]

将软件工程与土木工程进行比较时，我惊讶地发现了另一种思维方式：任何土木工程师都知道，如果您想在花园中建造一个小木屋，则只需获取材料并进行建造，而如果您要建造一栋10层高的房子（或类似这样的房子），您需要做一些数学运算以确保它不会崩溃。

相反，在与一些程序员交谈或阅读博客或论坛时，我经常发现一种广泛的观点，可以或多或少地提出如下观点：理论和形式方法适用于数学家/科学家，而编程则更多地是要把事情做好。

这里通常暗示的是编程是非常实用的东西，即使形式方法，数学，算法理论，简洁/连贯的编程语言等可能是有趣的主题，但如果所有人都想得到东西，通常就不需要它们了。完成。

根据我的经验，我想说的是，虽然您不需要太多理论来编写100行脚本（小屋），但是要开发复杂的应用程序（10层建筑），则需要结构化的设计，定义的方法，良好的编程语言，可在其中查找算法的良好教科书等。

因此，IMO（适量的）理论是完成任务的工具之一。

我的问题是，为什么有些程序员认为理论（形式方法）与实践（完成任务）之间存在差异？

与土木工程（房屋）相比，软件工程（房屋软件）是否被许多人认为 容易？

还是这两个学科真的不同（除了关键任务软件，软件故障比构建故障更容易接受）？

我尝试总结一下，到目前为止，我已经从答案中了解了什么。

1. 与软件工程相反，在土木工程中，对于特定任务需要多少理论量（建模，设计）更加清楚。
2. 部分原因是因为土木工程与人类一样古老，而软件工程仅存在了几十年。
3. 另一个原因是软件是一种更具可变性的人工产品，具有更灵活的要求（可能会崩溃），不同的营销策略（可以牺牲良好的设计以便快速将其投放市场）等。

结果，要确定在软件工程中合适的设计/理论量是非常困难的（太少->凌乱的代码，太多->我永远无法完成），因为没有通用规则，而只有（很多）经验可以提供帮助。

因此，如果我正确地解释了您的答案，那么 对于真正需要多少理论的不确定性会导致一些程序员对理论的爱恨交加。

我认为主要的区别在于，对于土木工程而言，现实世界的物理作用是不断进行的，功能强大的现实检查，可以使理论保持理智并限制不良做法，而在软件工程中，同样没有强大的力量来保持不切实际的象牙塔概念作为劣质工艺的检查。

许多程序员在失控的理论方面有不良经验，这些理论成为完成事情的积极障碍（例如“可执行UML”，超官僚的开发过程）。相反，肮脏的骇客和补丁程序可以使您走得很远，尽管最终会很慢。正如您在最后一段中所观察到的那样：失败通常不是最终的，因此也没有问题。

软件工程和土木工程几乎没有共通之处。土木工程的工作受到其材料和环境物理特性的限制。土木工程师花费大量时间来学习土壤特性和材料特性。物理上，软件开发仅受处理器和可用存储速度的限制。两者都很容易理解，我们不会花很多时间研究它们。软件开发的主要限制是人的智力。而且没有两个开发人员是相同的。此代码可维护吗？通过谁？在Haskell中使用三行​​快速排序可能对某些人显然是正确的，但对于另一些人却难以理解。一个由两个人组成的团队可以在一个月内完成申请，而另一个由十个团队组成的团队则很难在一年内交付。

软件开发全都是设计，要设计的工件比任何制造的产品都要复杂几个数量级，并且每个工件都是唯一的。

作为一名或多或少诚实的机械工程师（有一些土木工程），成为程序员，然后是CS（AI）博士，然后是老师，然后又是程序员（对不起，软件工程师），我对这个一般主题。

在传统工程中

• 您必须了解数学和科学，因为您所做的一切都基于此
• 该领域的“英雄”是那些发明新事物，发现新思想，解决无法解决的问题的人

信息理论有一个适用于软件的“物理学”，但是软件工程师对此几乎没有了解，当然也没有应用。他们得到的最多理论是可计算性和big-O。

同样，我一直对那些认为了解编程就足够了，而他们并不需要了解其程序主题的人感到惊讶。

此外，不鼓励创新。不鼓励使用被认为是“可读性”的最小公分母组思维方法。（想象一下，如果鼓励航空或核工程师不要做任何可能使他们的初级同辈难以理解的事情。）

他们学习的东西，例如如何编写Web应用程序，都具有巨大的价值。水管工或电工的技能也是如此，但这不是工程知识。

如果我在大多数软件上走了弯路，并且做了一些不是最佳设计但可以完成工作的东西，那么没人会丧命。这也是花园中的小屋不需要与10层建筑相同的标准的原因。但是，我可以构建一个非常大型的应用程序，例如facebook，如果它搞砸了并且丢失了一些数据，或者其他什么，那实际上没什么大不了的。实际上，固定大型应用程序的基础也比替换10层建筑的基础更简单。一切都取决于环境，并计算风险。

我还可以安全地继续添加到应用程序中。您不能轻易地将一个10层楼高的新三楼扔进去（使其变成11楼）。如果愿意，我每天都可以向大型应用程序添加新功能。

现在，良好的设计使这一切在编程中变得更加容易。但是，糟糕的设计并非没有可能，而且风险是……笨拙的软件。通常不死。

忍受我这个。我有一点。

我曾经有一位教授告诉我，拖延会导致更多的拖延，尽管大多数人在经过一整夜的论文写作/填塞/编程后自言自语：“我再也不会这样做了。下次，我会提早开始早点做。” 根据我作为完美的拖延者的经验，我发现这是对的，这就是教授的解释原因：无论如何，拖延的经验在大多数情况下都是相对成功的。这是高风险/高回报行为。一段时间后，您会忘记所有的不愉快，而只记得获得的回报。因此，下一次拖延的诱惑更加诱人，因为您上次成功了。

我认为可以在这里比喻我们经常看到的“把事情做好”的编程技术。可能出于无知，懒惰或真正的时间限制的程序员或程序员团队采用“完成任务”的方法进行编程，将所有理论，数学和良好实践抛诸脑后。你知道吗？他们把事情做好。它不是优雅，漂亮或不可维护的，但是可以完成工作。也许不懂信号量中的分号的非技术主管会给他们“完成工作”的称赞。因此，下一次程序员尝试使用这种宽松的方法进行编程时，一切都会变得更加容易，因为嘿，它上一次有效了不是吗？这是“简单”的出路，除非您的穷人，

我曾经是那个可怜，不幸的人，也许你们中的许多人也是如此。我恳求你们所有人。不要轻易出路！:)

您的前提有缺陷。土木工程师在设计大型建筑物，桥梁，隧道等时使用工程技术的主要原因是，确保他们使用的材料（混凝土，结构钢等）数量最少，可以满足要求的安全标准。如果没有材料和劳动力成本的问题，那么完全有可能在没有数学方法的情况下建造高层建筑（例如，古埃及和玛雅文明的金字塔），但是一旦建造起来，通常没有必要进行修改他们使他们更有效地使用材料。

在设计大型软件系统时，动力有所不同。如果有的话，它们通常设计得不够好，但这是因为设计可以随着工作的进行而动态地更改，而对于土木工程项目而言，这是不容易做到的。

共同因素是成本。在传统的土木工程项目上进行设计可以降低成本（实际成本，材料成本和潜在责任成本），而在软件开发中，设计成本的增长超过了返回的价值。

我还要指出，除了其他几个出色的回应之外，自埃及人时代以来，人类一直在做相当于“土木工程”的事情，所以我们有很多时间来完善关于事物应该如何变化的一般理论。完成。我们已经开发软件大约70年左右了（取决于您认为第一个“软件”的多少）；我的意思是，我们没有相同的时间来开发相同类型的体验。

建筑师/土木工程师的蓝图实际上从未与“竣工”计划相同。总是有变化。为什么？因为存在并且将永远存在“未知的未知数”。有些事情您知道并且可以计划，一些未知的事情可以进行研究和评估，然后有些事情您可能会不知道。“惊喜”。您的目标是通过学习全部知识来消除大多数系统中的这些问题，但所需要做的只是一点点违反建筑法规（这可能基于两年前概念化建筑物时还不存在的规则），包含总体规划，有时甚至是彻底改变。

软件非常像这样；总有一个未知的未知数。但是，与土木或结构工程不同，基于未知的未知因素所产生的问题，软件开发本质上更能容忍变更。如果您要建造一幢10层的建筑物，而您高估了您在设计中放置的地基的承重能力，那么您要么无法将建筑物建造成10层，要么必须付出大量工作才能回到基础并加固或重建它。但是，在软件中，如果您低估了整体解决方案结构中特定层的需求，则有许多用于修复该层的选项不会涉及使所有其他工作无效。您可以将一台数据库服务器替换为功能更强大的服务器，或者复制/故障转移群集，或负载平衡/分布式群集。对于网络服务器也是如此。如果您基于错误的输入大小假设编写了效率低下但简单的算法，则几乎总是可以简单地以相对手术的方式删除并重写实现，而不会影响其他了解该算法的代码（调用并将输入传递给它，或期望它的输出）。

这种相对容易的更改使软件工程师可以根据自己的知识进行编码，而不必担心自己不知道的内容。这使得理论和前期概念设计的应用更加宽松；您将潜入并完成它，并一路找到需要更改的编码内容，然后进行更改。您仍然必须了解概念和理论，因为当发现问题时，正是这些东西将帮助您确定原因并创建解决方案。但是，您可以在不屈服于“分析瘫痪”的情况下做出快速决策，因为如果事实证明您是基于您不知道或未考虑“计算”的内容而做出了错误的决定，错误更容易纠正。

区别主要是由于已知的要求：

• 从理论上讲，所有内容都是预先定义的，因此您可以在开始之前确切地知道您需要什么。
• 在实践中，它们通常并不存在，或者您在实施过程中发现了一些东西，使您不得不重新设计某些东西。因此，最好至少使用基本的设计，这样您才能尽早发现这些问题。

另外，在谈论“理论”时，它通常是指计算机科学的理论方面，而不是软件工程。这是计算机科学的一部分，主要涉及寻找更好和更高效的算法，证明是否有可能（例如P和NP），等等。尽管最好将它们放在脑海中，但它们并不经常出现在软件开发中。

我们尽可能地将库用于此类事情。

实际上，根据要构建的软件正在执行的工作，软件工程水平相当高。

NASA需要软件来控制太空中的载人航天飞机，因此自然而然，其工程过程的水平比建立一个网站显示火箭图片的过程严格得多。

我在NASA工作的一位同事先前将他们的软件工程过程描述为编写数百页的理由和数百小时的会议以证明编写一行代码是合理的！

不要误解我，因为我在讲话时并不是想表现出不敬，而是即使经过所有时间，资源和数十亿美元的花费，航天飞机仍然爆炸。

甚至土木工程师都知道，无论他们在设计中投入多少理论，某些东西最终都会破坏它，因此，他们还需要制定应急计划。

在构建软件时，它崩溃的代价很少会导致生命损失，因此快速地将东西扔出去并进行测试驱动要容易得多。我们同意，快速完成工作会导致代码不足。即使总是这样，让软件运行起来是开发人员了解弱点和需要变得更强大的地方的最佳方式，而不是弱点并且仍然比需要跟上很多倍的地方强的最佳方式。负载。

总结一下，Premature optimization is the root of all evil 或者就像我老板经常说的Shipping is a feature!

这里有很多好的答案，但我认为计算机科学与土木工程之间的比较是有缺陷的。

严格来说，专业软件开发人员的工作更像是软件工程，而不是计算机科学。更好的类比是计算机科学是软件工程的物理学。同样，民事工程学是物理的简化和近似集合，用于实际建造建筑。

我认为土木工程师在工作时很少需要考虑广义相对论。牛顿力学可以安全地构建许多土木工程。同样，只要对理论计算机科学有大致的了解，就可以非常成功地完成软件工程。

最大的区别是桥梁，摩天大楼和土木工程的其他产品都是相当容易理解的东西。软件工程师经常在构建新颖的结构，或使用新颖的方法来构建易于理解的事物。软件工程的远不如土木工程成熟，并且在可预见的将来，这仍将继续存在。

TL; DR：软件工程中的理论和实践不同，就像其他地方一样。恰当的类比是软件工程：土木工程：：计算机科学：物理。但实际上，它要复杂得多：)

所以我的问题是，为什么有些程序员认为理论（形式方法）与实践（完成任务）之间存在差异？

构建软件不同于构建桥梁。在软件中，有许多要构建的对象可能在开始时就已定义或未定义。存在标准以提高维护和开发人员协作的便利性，而不是遵循任意的数学公式或其他此类理想。例如，当基于变量选择行为时，有时使用开关（有时是工厂模式）是有意义的。这取决于维护的难易程度和确定的痛点，例如性能问题。

可以用数据操作来做另一个例子。在.NET上下文中使用委托通常很有意义。在Java中并不是那么容易，因为它不具有.NET所具有的对功能编程风格的框架支持。换句话说，在一般情况下，根本不可能在情况Y下执行X。这是由于X和Y依赖于N个可变因素。

与土木工程（房屋）相比，软件工程（房屋软件）是否被许多人认为容易？

我不确定“简单”是否正确。缺乏切实的证据可能导致人们认为没有工作要做。或者，类似地，现有工作很容易更改。

还是这两个学科真的不同（除了关键任务软件，软件故障比构建故障更容易接受）？

由于我已经说过的原因，传统工程和软件工程有很大的不同。

您的想法在这里可能是错误的，或者它包含许多尚未编写足够复杂软件的人提供的资源。

您的经验与我所了解的大多数人（设计并编写足够复杂的软件）所讲的内容一致。

就是说，对于大多数程序员而言，当编写东西的任务交给他们时，设计人员（正如您所说的那样，就是“数学”）已经由架构师/ lead / etc完成。在他们完成写作任务之前。因此，从一线层面可能会出现这种情况。

我认为这种对比的原因是软件项目和硬件或体系结构项目的生命周期不同。大多数软件是逐渐发展的，没有从头到尾进行计划。软件开发人员可以将迭代方法应用于开发：计划，实施和倾听反馈。如果反馈是正面的，那就继续，否则-不退一步，重新考虑您的策略。这就是软件开发人员拥有诸如敏捷开发，最低限度可行产品之类的东西的原因。

土木工程师没有这种奢侈。对于他们来说，一旦计划了某些事情，就无法像软件那样轻松地进行更改，因为更改的成本可能很高。另一方面，对于软件开发而言，它并不需要花费那么多钱，并且可以利用这些优势。

但是，并非软件开发的每个分支都能负担得起这种方法。例如，为航空或医疗服务制作软件需要非常仔细的计划和大量的事先计算。

对我来说似乎一样。您用标准砖块，标准强度混凝土，标准钢建造了大型建筑物。您可以使用标准库构建一个大型应用程序。

您无需尝试以数学方式正式证明大型应用正确无误，而无需尝试编写100层建筑物的wave函数

在20年前发现我的才能在于软件之前，我曾是机械和制造工程师。我同情您提出的许多要素。

我怀疑问题的真正本质在于我们如何完成工作。现在，我们已经在集体的领导下进行了大约十年的敏捷开发，而且信息很明确。不要分层进行；按功能进度。当然-有一些项目需要您逐级进行（例如，在Web服务器之前构建网络堆栈），但是对于绝大多数现实世界项目，我们已经吸取了教训，即交付工作功能，一个或几个一次，建立巨大的未经检验的理论，然后尝试实施这些理论要有效得多。

因此，让我们以您的小屋为例（我通常说的是通过跨河与一公里长的悬索桥之间的距离投掷日志来建立桥梁……等等！），并将其带入软件工程领域。我看到的主要区别是，在软件中，大多数工作都是在规模上完成的，不需要大的前期建模即可成功。初学者的错误通常是假设事情需要比实际需要更多的东西，对于我们大多数人来说，几次犯了这个错误，我们很乐意再次犯错。

无可争辩-有些项目需要从一个由17位软件架构师组成的委员会开始。实际上，它们大约只有20克拉钻石稀有。

我认为这个比喻是有缺陷的。据我所知，土木工程与计算机科学没有相同的理论基础。计算机科学源于理论数学，例如图灵机。土木工程是关于创建抵抗大自然的结构，甚至看起来很漂亮的结构。再说一次，我对土木工程真的并不了解，但是我认为并没有P，NP，旅行推销员等土木工程人员，还有其他一些有趣的事情让您耳目一新。我们的计算机科学理论绝对有一个地方-如果有人解决了旅行推销员或停工的问题，我们将获得许多令人敬畏的新进展。但是对于以设计软件为业务的软件工程师来说，这些问题实际上只是娱乐和游戏。

现在，我还认为这取决于您所说的“理论”。我们是在谈论设计模式，还是在推动引理？因为对设计模式有扎实的了解对于成为一名优秀的软件工程师至关重要。但是，在设计大型软件系统时，对P / NP问题进行理论化是没有用的。从这个意义上讲，我相信软件工程与理论计算机科学之间存在着非常鲜明的对比。

还是理论是指算法？您无需花费太多时间来编写在​​算法课中学习的算法。为什么？因为通常只在特定情况下需要它们（然后您进行查找和研究），或者使用已经为您编写的库。无需编写其他贝叶斯分类器。抽象是计算机科学中的重要原理。我认为软件工程师倾向于直到需要时才学习算法的工作原理。

另一个原因是当前存在几种有效的流行的“完成”软件开发方法。例如，在敏捷开发中，您不必事先设计整个系统。这样做的原因是因为您尚不完全知道自己要构建的内容，而是希望自己所做的事情变得灵活并适应新的信息和要求。一开始就进行全部设计，然后进行构建并不能始终生产出最好的软件。但是，这并不是所有解决方案。例如，假设您正在设计一些分布式计算集群疯狂的新事物。您无法做一些餐巾素描并开始SCRUM。

TL; DR。我认为“理论”一词有些模棱两可。传统上，理论是指计算机科学的理论数学方面。除非您正在研究更新的计算方式，否则在很大程度上，理论计算机科学在软件工程师的日常生活中不起作用。软件工程师关心设计模式和系统架构。某些算法的具体实现细节并不重要。通常情况下，想法不那么复杂，不进行太多设计而只是开始编码是合适的。我认为这是程序员不喜欢理论的想法。

目前，理论与实践之间的差距过大。在进行理论分析时，会给您三个公理，随后证明单行定理具有一千页证明或根本没有证明。在软件工程中，您会获得数千个功能不一致的API，这些API会给您带来多种（不好的）实施未指定功能的方式。

真正的软件工程会驱使大多数从事正规领域的人，而真正的数学软件开发会驱使那些从事工程学的人。这两个领域都需要具有不同才能的人，我不认为这些能力经常重叠。

形式理论假设您可以像制造产品一样提前准确地计划所有事情，软件将无限期存在于同一环境中，并且解决一般抽象问题始终是目标。它假设4D软件即产品的生命周期为：设计，开发，部署，完成。形式理论是关于使用分析，抽象，概括和预测未来变化来解决软件设计问题。如果您在易于分析，可预测且相当静态的直截了当的领域中遇到明确定义的问题，那么这很好。

实用的编程是关于立即以正确的方式解决正确的问题（而不是软件设计的问题），以便您的同事可以更好/更快/完全地完成工作，或者使收入流入公司。许多软件不是像一种产品，永远不会“完成”，而更像是一种生物，它开始专门针对一种生态位，并且可能具有广泛的寿命，在此期间，它需要解决新的不可预见的问题。各种各样不断变化的环境。在商业世界中，由于政治，法律和竞争以及不断变化的组织，结构和趋势，要求常常是模棱两可的，并因各种特殊情况而混乱，定义不清，并且会迅速发生意料之外的变化。它们不是可分析，不可预测或静态的，而且通常不合逻辑或不合理。该软件可能在2周内无关紧要，而在20年后仍会继续使用。它进入世界以来并不了解很多东西或做不了很多事，因此需要在其一生中进行培养，修饰和培训，以使其变得强大，灵活，并能够适应日新月异的环境和新问题。如果您在出生后忽略它，它会存活很长一段时间，并且会造成疼痛和痛苦，并用钝器解决问题。

形式理论无法解决许多现实世界中商业软件的需求。它使我们相信可以设计和完成软件。它是一种可以偶尔固定，抛光或粘着东西的产品，而不是需要在其整个生命周期中不断加以照顾和关注的生物。因此，我们最终得到了非常丑陋的野性遗留代码，但是形式化理论可能对此没有帮助。

所有这些听起来都是负面的，但实际上，我喜欢使用形式理论。美丽的设计总能带给我微笑。但是，这主要是在我的业余爱好者编程中，不受业务沧桑的影响。在工作中，我主要处理有机代码，只是希望我能给予它足够的关注，以使它能够正确成长，让我感到骄傲，并且对需要处理的其他人不会感到讨厌和粗鲁。

赌注更低，工作更轻松，管理层很少看到良好设计的价值。系统的不稳定性，可维护性和完整性是一个“ IT”问题，而不是一个“业务”问题。所有高管有一个共同点。他们要么95％专注于金钱，要么向某人报告。

剩下的战斗是与您的程序员同行。他们中的许多人不能或不会致力于在编码开始之前就思考问题。由于上述原因，这些人中有很大一部分是高级开发人员，这使得将好的设计投入生产变得更加困难。

我已经看到项目负责人浪费了数年的时间来为一开始就艰难的项目添加临时功能和修复程序，然后拒绝使用“太复杂”或“浪费时间”这样的短语来使混乱的秩序一切尝试。看到一个大型项目陷入不可避免的厄运是令人不愉快的，因为管理层不会承认他们每天都在建造自己的监狱。但是，我担心许多开发人员已经目睹并从中吸取了教训，这是一个不幸的现实。

我试图在我的工作中找到一种媒介。我在“污染”项目中编写的代码没有超出绝对必要的数量，并且我会抓住一切机会将功能移出它们。在“项目之间”，我花了一些时间在实际上由我控制的项目中进行设计和清理。

最后，世界上75％的程序员没有能力忍受很大的政治和个人诚信混乱。我自己几乎受不了。

首先，我喜欢这个问题。我写了三个1000字的答案，而到我写完答案时，它们全都错了。

我认为，尝试将两者进行相似性比较时存在的问题是，编程是一个建模过程，可以根据需要任意抽象或紧密绑定。

另一方面，结构工程理论与您必须遵守的非常具体的基于现实的定律紧密相关。您不能只是更改上下文或法律。问题本身就根植于这些法律。但是，在编程中，有时解决方案实际上是在改变问题的性质，或者只是将其置于不同的上下文中。

例如，MVC模式是否完美匹配与该上下文有很大关系。桌面应用程序通常仅处理一种语言和一种语言，不计算配置文件。

另一方面，Web应用程序的前端主要由两种声明性（非编程）语言和JavaScript组成。您不能完全抽象的一件事是，始终存在此http墙以在服务器和浏览器之间交换内容。无论您如何将其埋在代码中，这都需要时间和异步设计。

显然，您不能使用MVC之类的流行且广受好评的模式来专门处理Web上的前端问题，而又不改变在桌面应用程序上下文中处理它的方式。实际上，我会辩称，您应该知道使MVC有用的原因，但不要尝试以特别严格或全面的方式实施它。Web应用程序范式的独特之处在于，所有“我看”东西都是由用户的浏览器处理的，而所有“数据/模型”东西通常都在服务器上的某个位置。但是，控制器又在哪里呢？全部在服务器上还是全部在前端？有人必须拥有它。也许MVC并非100％最适合这种情况。.NET后端的东西不错。在特定的UI小部件的上下文中并不可怕。

盖房子可以解决问题。但是，典型的编程问题通常涉及解决问题中的问题，有时解决方案是重新定义外部问题。不幸的是，现实并不特别喜欢这个想法。

格伦·范德堡（Glenn Vanderburg）很好地介绍了软件工程与更传统的工程学科之间的区别：http : //www.youtube.com/watch?v=NP9AIUT9nos

如果土木工程师在建造最终产品之前可以免费测试其设计，那么他将减少理论的运用。如果在几秒钟内他可以免费建造一千座桥梁以测试何时会断裂，他会这样做，而不是花费数月的时间计算理论上何时会断裂……

在软件开发中，这正是您的工作。无需计算理论上的算法速度，您只需对其进行测试即可在几秒钟内知道答案。

实际上，当今大多数软件不再受诸如计算能力或内存之类的物理约束的限制。软件的局限性在于越来越大的系统中的复杂性。它通过保持人类可理解的系统来管理这种复杂性，这给当今的编程带来了巨大的挑战。