优化有危险吗？

Question

我在“堆栈溢出”中的一个问题的注释部分中读到了这样的内容：

始终开始未优化的编码。如果它符合要求，那么它是好的，否则就编写一个优化版本。检查优化的代码是否满足需求，如果它满足需求，保留它，但也保留未优化版本或粘贴未优化版本作为注释。如果优化后的版本不符合要求，请删除它并坚持使用未优化的版本。

这种编程有术语吗？这是一个好的还是坏的编程实践？

优化有危险吗？我能想到的唯一原因是，它会造成不必要的复杂性，从而导致错误。还有别的事吗？

关于什么时候应该进行优化，是否需要遵循一般规则？

Answer 1

优化代码需要开发人员花时间，他们可以使用这些代码来添加新功能或改进产品。由于开发的最终目标不是代码，而是用代码构建的产品，因此，在优化上的时间应该与当时可以完成的其他用途相平衡。

如果在代码上花费的精力并不会因为需求的更改而最终出现在产品中，那么这是一种浪费。如果从一开始就执行优化，那么您也可能会花费大量的时间来优化代码的一部分，这部分代码只对应用程序所花费的全部时间做出了微小的贡献。

相反，您可能应该等到对应用程序和瓶颈有了明确的了解之后，才会在优化上花费太多的精力。然后，您将拥有大量的单元测试和用例套件，这些测试和用例将使您能够自信地进行优化，即您不会破坏应用程序，并且只会将您的精力花在真正值得优化的部件上，这要归功于概要分析。

就像在工程中一样，优化是你做出的一种权衡。如果你在意你的资源(时间，金钱，.)，你肯定会在做之前得到回报。

Answer 2

一般来说，优化代码比较复杂，很难得到正确的处理。尽早优化代码也常常适得其反(仅仅是因为您可能会花费时间来优化一些没有真正改善整体性能的东西)。

所以你所要求的指导实际上可以归结为：

• 编写易于编写的代码，并验证其正确性
• 优化代码时，这是有意义的花费努力。

不管运行速度有多快，不正确的代码都不是优化的代码。

Answer 3

优化前一定要分析一下。如果少量的代码占用了大部分的执行时间，并且您可以从分析结果中证明这一点，那么可以考虑编写、测试、重新配置、维护和让其他人继承这种额外的复杂性的编程工作。完成此操作后，将代码还原回运行时优化之前的代码，并为可读性而对其进行去优化。别这么做。说真的，除非你90%以上的执行都花在了一个功能上，否则这是不值得的。

请记住，在消耗运行时90%的代码上加速比10倍，将使您的运行时减少5倍。在这个缓慢的函数上加速无穷，仍然只会将整个程序的速度提高10倍。如果您希望提高一个数量级以上的速度(这是我是否可以开始考虑优化的门槛)，您将需要改变处理问题的方式，而这种变化意味着重新考虑程序的结构。如果幸运的话，它可能就像用优先级队列替换队列一样简单。很可能你不走运。对不起，答案是暗淡的。