我在软件行业工作了两年 . 让我困惑的一些事情如下：
- 当前软件行业缺乏数学应用 .
例如：当机械工程师设计电线杆时，他通过使用应力分析技术（读取数学方程式）来计算基础上的应力，以确定应该使用何种钢材和钢材等级，但是当软件开发人员部署网络时服务器应用程序，他只是猜测他的服务器上的估计负载，其余的运气和上帝，他没有什么可以用来模拟数学来回答他的问题（我的观察） .
-
伟大的软件（风洞模拟器等）和计算程序（如matlab等）可以模拟现实世界的问题（因为它们有他们的数学方程式）但我们在软件行业仍然无法知道有多少实际资源的内存，当我们的服务器端应用程序实际部署时，将需要计算资源，时钟速度，RAM等 . 我们只是继续猜测解决方案并通过或多或少的“命中和试验”来解决这个问题（我的观察） .
-
编程是在API上进行的，无论是在c，C＃，java等中 . 我们永远无法准确检查代码的复杂性，从而无法检查效率，因为我们正在使用其他人编写的抽象，其源代码我们要么没有我们还是没有时间检查它 .
例如如果我用C＃或java编写一个简单的客户端服务器应用程序，我永远无法事先计算出这个代码的效率和复杂程度，或整个客户端服务器应用程序需要的最小值（我的观察） .
- 负载均衡和可扩展性分析过于模糊，仅在服务器上的请求增加时添加更多节点才能解决（我的观察） .
请发布以上任何令人费解的观察结果的答案 . 请发布相关参考资料 .
如果有人证明我错了并且表明正确的方式，我会很高兴 .
提前致谢
阿希什
12 回答
我认为这有几个原因 . 一个是，在许多情况下，简单地完成工作比使其尽可能好地完成更重要 . 我编写的很多软件只会在小数据集上运行，或者性能影响非常小的东西（它是一个对每个元素进行固定计算的循环，所以它通常是O（n） ） . 对于大多数此类软件，花时间详细分析运行时间是愚蠢的 .
另一个原因是软件以后很容易更改 . 一旦你构建了一个桥梁，任何修复都会非常昂贵，所以在你做之前确定你的设计是件好事 . 在软件中，除非你早期做出了糟糕的架构选择，否则一旦你掌握了一些关于它的表现的更真实的数据，你通常可以找到并优化性能热点 . 为了避免那些可怕的架构选择，您通常可以进行近似的，包络后的计算（确保您不在大型数据集上使用O（2 ^ n）算法，并在一个因子内进行估计10个左右你需要多少资源来满足你预期的最重负荷 . 这些确实需要进行一些分析，但通常它可以非常快速地脱离袖口 .
然而，在某些情况下，您确实需要从系统中挤出最终性能 . 在这种情况下，人们经常会坐下来，计算出他们正在使用的系统的性能特征，并进行非常详细的分析 . 例如，见Ulrich Drepper的非常令人印象深刻的论文What Every Programmer Should Know About Memory (pdf) .
想想工程科学，他们都有非常明确的法律适用于设计，物理项目的建设，重力，材料的强度等等 . 而在计算机科学中，没有很多明确的法律，当它来构建一个应用程序 .
我可以想出许多不同的方法来编写一个满足要求的简单的hello world程序 . 但是，如果我必须建造一根电线杆，我受到物理世界以及极点要求的严重限制 .
一点一点地说
电杆必须能够承受天气，负载，腐蚀等这些可以量化和建模 . 我无法量化我的网站发布成功，或我的数据库将如何增长 .
过早优化？确实足够好，在需要时修复它 . 如果您是供应商，您不知道在现实生活中运行代码的方式或配置方式 . 你再也无法量化它 .
过早优化
参见第1点 . 我可以根据需要添加 .
继续...甚至工程师bollix . 倒塌的桥梁，停电，汽车安全召回，“错误的雪”等等 . 我们是否应该将问题改为“为什么工程师不使用更多的经验观察？”
大多数问题的答案是，为了获得实际工程中有意义的测量结果（以及公认的公式，限制，公差等），您首先需要一种衡量您所看到的内容的方法 .
大多数这些东西根本无法轻易测量 - 软件复杂性是一种经典，什么是“复杂”？您如何看待源代码并确定它是否复杂？ McCabe的Cyclomatic Complexity是我们最接近的标准，但它基本上只是计算方法中的分支指令 .
软件程序中的数学很少，因为程序本身就是等式 . 在实际运行之前无法计算出等式 . 工程师使用简单（和非常复杂）的程序来模拟现实世界中发生的事情 . 模拟模拟器非常困难 . 此外，计算机科学中的许多问题甚至没有数学上的答案：见旅行推销员 .
大部分数学也包含在语言和图书馆中 . 如果使用哈希表来存储数据，则无论哈希表中有多少个元素，您都知道可以在常量时间O（1）中找到任何元素 . 如果将它存储在二叉树中，则需要更长的时间，具体取决于元素的数量[0（n ^ 2），如果我没记错的话] .
问题是软件与人类编写的其他软件进行对话 . 您描述的工程示例处理的物理现象是不变的 . 如果我开发一个电子模拟器，世界上每个人都可以使用它 . 如果我为我的服务器开发协议X模拟器，它将帮助我，但可能不值得工作 .
没有人可以从头开始设计系统，编写半公共库的人通常会有大量的增强功能和扩展功能，而不是为他们的库编写模拟器 .
如果你想要一个网络流量模拟器你可以找到一个，但它会告诉你很少有关你的服务器负载，因为流量将不会使用你的服务器理解的协议 . 每台服务器都会看到完全不同的流量集 .
我不会说运气或上帝总是负荷估算的基础 . 通常可以获得真实的数据 .
没有数学技术来回答这个问题也是不正确的 . 运筹学和排队论可以很好地应用 .
真正的问题是机械工程基于物理定律，是数千年经验和科学研究的基础 . 计算机科学只和我一样古老 . 当您的孩子和孙子女应用当时的最佳实践时，计算机科学将会更进一步 .
麻省理工学院的EE毕业生不会有这个问题;）
我的想法：
有些人确实应用数学来估算服务器负载 . 对于许多应用来说，方程式非常复杂，许多人采用经验法则，猜测和调整或类似的策略 . 一些应用（对故障进行高惩罚的实时应用......武器系统，动力装置控制应用，航空电子设备）仔细计算所需的资源并确保它们在运行时可用 .
与1相同 .
工程师也使用组件由其他人提供，具有已发布的界面 . 想想电气工程 . 您通常不关心晶体管的内部，只是它的接口和操作规范 . 如果您想要检查您使用的所有组件的复杂性，那么您将受限于单个人可以完成的任务 .
我编写了相当复杂的算法，根据各种因素（如内存消耗，CPU负载和IO）确定要扩展的内容 . 但是，有效的解决方案有时需要进行测量和调整 . 如果应用程序很复杂并且随着时间的推移而发展，则尤其如此 . 投入数学建模应用程序（并随着时间的推移更新该模型）所付出的努力可能不仅仅是通过尝试和正确方法损失效率的成本 . 最终，我可以设想更好地理解代码与其执行的环境之间的关联可能会导致系统提前预测资源使用情况 . 由于我们今天没有，许多组织在各种条件下加载测试代码以经验地收集该信息 .
软件工程与典型的工程领域截然不同 . 在“正常”工程受到我们物理世界的背景以及我们已经确定的规律的约束下，软件世界中没有这样的边界 .
制作软件通常是试图将现实世界的一部分镜像到虚拟现实中 . 在这里，我们自己定义法律，只选择我们需要的法律，并使它们尽可能复杂 . 由于这种根本区别，您需要从不同的角度来看问题解决 . 我们尝试进行抽象，使复杂的部分变得不那么复杂，就像我们教孩子那样黄色的蓝色=绿色，当它真正地反射在纸张上的光的波长发生变化时 .
偶尔，我们受到不同法律的约束 . 像Big-O，测试覆盖，复杂度测量，UI测量等等都是数学定律的模型 . 如果你研究数字信号处理，实时编程和函数编程，你会经常发现程序员使用方程来找出他们想要的方法 . - 但是这些技术并不是（在某种程度上）对创建虚拟域有用，可以解决复杂的逻辑，分支和与用户交互 .
在工程领域中需要风洞，模拟等的原因是，构建缩小的原型要比制造完整的东西然后测试它要便宜得多 . 此外，对全尺寸桥接器的测试失败是破坏性的 - 您必须为每个测试构建一个新的测试 .
在软件中，一旦您拥有满足要求的原型，您就拥有了全面的解决方案 . 没有必要构建完整版本 . 您应该在使用它们之前对服务器应用程序运行负载模拟，但由于负载是可变的并且通常是不可预测的，因此您最好通过添加更多硬件来构建应用程序以扩展到任何大小，而不是针对特定目标 . 加载 . 桥构建器具有需要处理的给定目标负载 . 如果他们在任何特定时间预计使用10辆汽车，那么一年之后，这座桥的人气每天飙升至1,000,000辆汽车，如果失败，没有人会感到惊讶 . 但是对于Web应用程序，这就是必须进行的扩展 .
1）大多数业务逻辑通常分解为决策树 . 这是应该用单元测试证明的“等式” . 如果你输入x那么你应该得到y，我没有看到任何问题 .
2,3）分析可以提供关于性能问题所在的一些见解 . 在大多数情况下，您不能说软件会占用x个周期，因为它会随着时间的推移而变化（即数据库变大，操作系统开始变得时髦等） . 例如，桥梁需要不断的维护，你不能把它打起来，并期望它可以持续50年而不花费时间和金钱 . 使用库就像不想在每次想要找到圆周长时找出pi . 它已被证明（并且具有成本效益），因此无需重新发明轮子 .
4）大多数Web应用程序可以横向扩展（多台机器） . 垂直（多线程/多进程）扩展往往要复杂得多 . 添加机器通常相对容易且成本高有效并避免一些容易受到限制的瓶颈（磁盘I / O） . 负载 balancer 也可以消除一台机器成为中心故障点的可能性 .
它并不完全是火箭科学，因为你永远不知道有多少消费者会来服务线 . 一般来说，有太多的容量然后有错误，最好是顾客和某人（通常是你的老板）咀嚼你的隐藏 .