我们应该在慢箱上开发，因为它迫使我们尽早优化。
Randall Hyde 在The Fallacy of Premature Optimization 中指出，围绕着 Hoare 的名言存在很多误解：
我们应该忘记小的效率，比如大约 97% 的时间：过早优化是万恶之源。
特别是，尽管如今的机器与 Hoare 时代的机器相比尖叫，但这并不意味着“应该避免优化”。那么，当我尊敬的同事建议我们应该在适度节奏的盒子上发展时，他是否有道理？这个想法是，性能瓶颈在慢速机器上更令人恼火，因此它们很可能会受到关注。
【问题讨论】：
标签： premature-optimization developer-machine
这应该是社区 wiki，因为它非常主观，并且没有“正确”的答案。
也就是说，您应该在可用的最快机器上进行开发。是的，任何较慢的东西都会引起刺激并鼓励您解决减速问题，但代价非常高：
作为一名程序员，你的工作效率与你可以在脑海中掌握的东西的数量直接相关，任何减慢你的进程或完全阻碍你的事情都会延长你在短期内持有这些想法的时间——记忆力，让你更容易忘记它们，而不得不去重新学习它们。
等待程序编译会在您分心时让一堆错误、潜在问题和修复从您的脑海中消失。等待对话框加载或查询完成同样会打断您。
即使你忽略了这种影响，你仍然知道后面那句话的真相 - 早期的优化会让你绕着圈子追逐自己，破坏已经有效的代码，并猜测（通常准确度很差）事情在哪里可能会陷入困境。首先正确地设计代码，然后您可以忘记优化，直到它有机会安顿下来，此时任何必要的优化都会很明显。
【讨论】：
取决于您的交货时间。如果您处于 12 个月的交付周期，那么您应该以相当快的速度开发盒子，因为您的客户从现在开始的 12 个月将拥有比当前“平均”更好的“平均”盒子。
随着您的开发周期接近“今天”，您的开发机器应该接近客户机器当前的“平均”速度。
【讨论】：
我想这将取决于您正在制作什么以及目标受众是什么。
如果您正在为固定硬件（例如主机游戏）编写软件，那么请使用与您要部署的设备相似或相同的设备（至少是测试设备）。
如果您正在开发桌面应用程序或该领域的其他东西，请在您想要的任何机器上进行开发，然后对其进行调整以在所需的最低规格硬件上运行。同样，如果您正在开发内部软件，公司想要购买的机器可能会有最低规格。在这种情况下，请在快速机器上进行开发（以减少开发时间并因此降低成本）并针对该最低规范进行测试。
底线是，在您可以使用的最快的机器上进行开发，并在您将支持的最小或精确硬件上进行测试。
【讨论】：
我通常在我能拿到的最快的机器上进行开发。
大部分时间我都在运行调试版本，这已经够慢了。
【讨论】：
慢速计算机不会帮助您发现性能问题。
如果您的测试数据在表中只有几百行，那么您的数据库会将其全部缓存，您将永远不会发现编写错误的查询或错误的表/索引设计。如果您的服务器应用程序不是多线程服务器，则在对 500 个用户进行压力测试之前，您不会发现这一点。或者如果应用程序的带宽瓶颈。
优化是“一件好事”，但正如我对那些对如何做得更好有各种想法的新开发人员所说的那样，“我不在乎你多快给我错误的答案”。先把它做好，然后当你发现瓶颈时让它更快。一个有经验的程序员会从一开始就设计和构建它。
如果性能真的很关键（实时？毫秒级事务？），那么您需要设计和实施一组基准和工具，以科学地向自己证明您的更改正在加快速度。影响性能的变量太多了。
此外，他们还会提出一个经典的程序员借口——“但它运行缓慢，因为我们故意选择了慢速计算机，当我们部署它时它会运行得更快。”
如果您的同事认为这很重要，请给他一台慢速计算机并让他负责“性能”:-)
【讨论】：
为了 Codd 的热爱，使用分析工具，而不是缓慢的开发机器！
【讨论】：
应该避免优化，这不是给我们Vista吗？ :p
但说真的，这始终是一个权衡问题。要问自己的重要问题
您的最终用户将使用什么平台？ 我可以放弃周期吗？如果我这样做会怎样？
我同意大多数人的观点，即初始开发应在您可用的最快或最高效（不一定相同）的机器上完成。但是对于运行测试，请在您的目标平台上运行它，并尽早进行测试。
【讨论】：
如果您在接近最终测试和生产环境的硬件上进行编程，您往往会发现在发布代码时没有那么令人讨厌的意外。
我已经看到足够多的程序员因为他们的机器比他们的大多数用户快得多而被严重但出乎意料的问题所困扰。但是，我也看到数据出现了同样的问题。代码在小数据集上进行测试，然后在大数据集上“崩溃”。
开发和部署环境的任何差异都可能导致意外问题。
尽管如此，由于编程既昂贵又耗时，如果最终用户运行缓慢的过时设备，更好的解决方案是在测试时处理它（并安排一些早期测试只是为了检查可用性和时间）。
为什么仅仅因为您担心错过潜在问题而削弱您的程序员？这不是一个明智的发展战略。
保罗。
【讨论】：
我认为这是一个合理的概念（但也许是因为它对我有用）。
如果我的开发人员工作站太快，我会发现我的想法不够彻底，因为在重新生成软件映像或将其下载到目标时几乎没有时间损失。我会说我至少有一半的下载是不必要的，因为我只是想起了我在调试代码之前错过的一些东西。
目标机器很可能包含一个受限制的处理器。如果 - 在嵌入式 MCU 上 - 你每秒有一半的 FLASH、RAM 和时钟周期，那么开发人员在设计他们的代码时会更加小心。我曾经为数据区（不是在 RAM 中，而是在串行 eeprom 中）中单个记录的长度建议字节变量，并收到“我们不需要小气”的回复。几个月后，他们达到了 RAM 上限 (128KiB)。我的想法是，对于这个应用程序，永远不会有任何大于 256 字节的记录，因为没有 RAM 可以将它们复制到。
对于服务器应用程序，我认为使用（很多）性能较低的硬件进行测试是个好主意。两个或四个核心而不是十六个（或更多）。 1.6 GHz isdo 2.8。名单还在继续。服务器通常 - 由于每个人都在与它交谈这一事实 - 系统架构中的瓶颈。这距离您开始为它开发（服务器）应用程序还早。
【讨论】：