Ewa*_*odd 5 developer-machine premature-optimization
我们应该在缓慢的盒子上发展,因为它迫使我们尽早优化.
Randall Hyde在"早熟优化的谬误"中指出,围绕Hoare引用有很多误解:
我们应该忘记小的效率,大约97%的时间说:过早的优化是所有邪恶的根源.
特别是,尽管机器现在比Hoare当天的机器尖叫,但这并不意味着"应该避免优化".那么,当他建议我们应该在适度节奏的盒子上发展时,我尊敬的同事有一个观点吗？这个想法是,性能瓶颈对慢速盒子更具刺激性,因此它们可能会受到关注.
Pau*_*lan 21
这应该是社区维基,因为它非常主观,并且没有"正确"的答案.
也就是说,您应该使用最快的机器进行开发.是的,任何慢的东西都会引起刺激,并鼓励你修复减速,但只是以非常高的价格:
作为一名程序员,你的工作效率与你能掌握的事物的数量直接相关,任何减慢你的过程或阻碍你的事情都会延长你在短期记忆中持有这些想法的时间,你更有可能忘记它们,并且必须重新学习它们.
等待程序编译允许堆栈的错误,潜在问题和修复程序在您分心时辍学.等待加载对话框,或者查询完成同样的中断.
即使你忽略了这种效果,你仍然可以得到后面声明的真实性 - 早期的优化将让你在圆圈中追逐自己,打破已经有效的代码,并猜测(通常精度不高)事情可能会陷入困境下.首先正确设计你的代码,你可以忘记优化,直到它有机会稍微解决,此时任何必要的优化都是显而易见的.
jqa*_*jqa 10
慢速的计算机无法帮助您找到性能问题.
如果您的测试数据只是表中的几百行,那么您的数据库将对其进行全部缓存,您将永远不会发现编写错误的查询或错误的表/索引设计.如果您的服务器应用程序不是多线程服务器,那么在用500个用户对其进行压力测试之前,您将无法找到它.或者,如果应用程序存在带宽瓶颈.
优化是"一件好事",但正如我对那些对如何做得更好的各种想法的新开发人员所说'我不在乎你多快给我错误的答案'.先找到它,然后在找到瓶颈时加快速度.一个经验丰富的程序员将从头开始设计和构建它.
如果性能真的很关键(实时？毫秒事务？)那么你需要设计并实现一套基准和工具来科学地证明你的变化使它变得更快.有太多的变量会影响性能.
此外,还有他们将带来的经典程序员借口 - '但它运行缓慢,因为我们故意选择慢速计算机,部署它时运行速度会快得多.
如果你的同事认为重要的是给他一台慢速计算机并让他负责"表现":-)