我们应该在慢箱上开发，因为它迫使我们尽早优化。
Randall Hyde 在The Fallacy of Premature Optimization中指出，围绕 Hoare 的名言有很多误解：
我们应该忘记小的效率，比如大约 97% 的时间：过早优化是万恶之源。
尤其是，尽管如今的机器与 Hoare 时代的机器相比尖叫，但这并不意味着“应该避免优化”。那么，当我尊敬的同事建议我们应该在适度节奏的盒子上发展时，他是否有道理？这个想法是，性能瓶颈在慢速机器上更令人恼火，因此它们很可能会受到关注。
问问题
467 次
9 回答
21
这应该是社区 wiki，因为它非常主观，并且没有“正确”的答案。
也就是说，您应该在可用的最快机器上进行开发。是的，任何较慢的东西都会引起刺激并鼓励您解决减速问题，但代价是非常高的：
作为一名程序员，你的工作效率与你可以在脑海中掌握的东西的数量直接相关，任何减慢你的过程或完全阻碍你的东西都会延长你在短期记忆中持有这些想法的时间，使您更有可能忘记它们，并且必须重新学习它们。
等待程序编译会让你分心时，一堆错误、潜在问题和修复从你的脑海中消失。等待对话框加载或查询完成同样会打断你。
即使你忽略了这种影响，你仍然得到了后面陈述的真相——早期的优化会让你在循环中追逐自己，破坏已经有效的代码，并猜测（通常准确度很差）事情可能会在哪里陷入困境向下。首先正确地设计你的代码，你可以忘记优化，直到它有机会安顿下来，此时任何必要的优化都是显而易见的。
于 2009-10-21T16:34:48.667 回答
10
慢速计算机不会帮助您发现性能问题。
如果您的测试数据在表中只有几百行，那么您的数据库将全部缓存，您将永远不会发现编写错误的查询或错误的表/索引设计。如果您的服务器应用程序不是多线程服务器，则在对 500 个用户进行压力测试之前，您不会发现这一点。或者如果应用程序的带宽瓶颈。
优化是“一件好事”，但正如我对那些对如何做得更好有各种想法的新开发人员说的那样，“我不在乎你多快给我错误的答案”。先把它做好，然后当你发现瓶颈时让它更快。一个有经验的程序员将从一开始就设计和构建它。
如果性能真的很关键（实时？毫秒级事务？），那么您需要设计和实施一组基准和工具，以科学地向自己证明您的更改正在使其更快。影响性能的变量太多了。
此外，他们还会提出一个经典的程序员借口——“但它运行缓慢，因为我们故意选择了慢速计算机，当我们部署它时它会运行得更快。”
如果您的同事认为重要的是给他一台慢速计算机并让他负责“性能”:-)
于 2009-10-21T16:51:34.173 回答
3
我想这取决于你在做什么以及目标受众是什么。
如果您正在为固定硬件（例如控制台游戏）编写软件，那么请使用与您将部署的设备相似或相同的设备（至少是测试设备）。
如果您正在开发桌面应用程序或该领域的其他东西，那么请在您想要的任何机器上进行开发，然后对其进行调整以在所需的最低规格硬件上运行。同样，如果您正在开发内部软件，公司想要购买的机器可能会有最低规格。在这种情况下，在快速机器上开发（以减少开发时间并因此减少成本）并针对该最低规格进行测试。
最重要的是，在您可以使用的最快的机器上进行开发，并在您将支持的最小或精确硬件上进行测试。
于 2009-10-21T16:36:36.230 回答
2
如果您在接近最终测试和生产环境的硬件上进行编程，您往往会发现在发布代码时没有那么令人讨厌的意外。
我已经看到足够多的程序员因为他们的机器比他们的大多数用户快得多而受到严重但意外的问题的影响。但是，我也看到数据出现了同样的问题。该代码在一个小数据集上进行测试，然后在一个大数据集上“崩溃”。
开发和部署环境的任何差异都可能是意外问题的根源。
尽管如此，由于编程既昂贵又耗时，如果最终用户运行缓慢的过时设备，更好的解决方案是在测试时处理它（并安排一些早期测试只是为了检查可用性和定时）。
为什么仅仅因为你担心错过一个潜在的问题就削弱你的程序员？这不是一个明智的发展战略。
保罗。
于 2009-10-21T19:40:20.010 回答
1
出于对 Codd 的热爱，使用分析工具，而不是缓慢的开发机器！
于 2009-10-21T17:01:58.550 回答
1
应该避免优化，那不是给了我们Vista吗？:p
但说真的，这始终是一个权衡问题。要问自己的重要问题
您的最终用户将使用什么平台？我可以放弃周期吗？如果我这样做会发生什么？
我同意大多数人的观点，即最初的开发应该在您可用的最快或最高效（不一定相同）的机器上完成。但是对于运行测试，请在您的目标平台上运行它，并经常和尽早进行测试。
于 2009-10-21T18:17:55.037 回答
0
取决于您的交货时间。如果您处于 12 个月的交付周期，那么您应该以相当快的速度开发一个盒子，因为您的客户从现在开始的 12 个月将拥有比当前“平均”更好的“平均”盒子。
随着您的开发周期接近“今天”，您的开发机器应该接近您客户机器的当前“平均”速度。
于 2009-10-21T16:35:24.173 回答
0
我通常在我能拿到的最快的机器上开发。
大多数时候我都在运行调试版本，这已经足够慢了。
于 2009-10-21T16:37:51.947 回答
0
我认为这是一个合理的概念（但也许是因为它对我有用）。
如果我的开发人员工作站太快，我会发现我的想法不够彻底，因为在重新生成软件映像或将其下载到目标时几乎没有时间惩罚。我会说至少有一半的下载是不必要的，因为我只记得在我要调试代码之前我错过了一些东西。
目标机器很可能包含一个受限制的处理器。如果 - 在嵌入式 MCU 上 - 你每秒有一半的 FLASH、RAM 和时钟周期，那么开发人员在设计他们的代码时会更加小心。我曾经为数据区（不是在 RAM 中，而是在串行 eeprom 中）中单个记录的长度建议字节变量，并收到“我们不需要小气”的回复。几个月后，他们达到了 RAM 上限 (128KiB)。我的反思是，对于这个应用程序，永远不会有任何大于 256 字节的记录，因为没有 RAM 可以将它们复制到。
For server applications I think it would be a great idea to have a (much) lower-performing hardware to test on. Two or four cores instead of sixteen (or more). 1.6 GHz istdo 2.8. The list goes on. A server is usually - due to the very fact that everyone talks to it - a bottleneck in the system architecture. And that is long before you start developing the (server) application for it.
于 2014-12-20T12:15:43.540 回答