在初始编码期间进行优化是一个好的实践吗?

优化你的设计和架构-不要把自己锁在一个永远无法扩展的设计中-但不要微观优化你的实现。尤其是,不要为微观优化的实现牺牲简单性和可读性…至少在没有首先对代码(理想情况下是整个系统)进行基准测试的情况下。

衡量是衡量绩效的关键。瓶颈几乎永远不会出现在你期望的地方。有很多不同的测量方法;在没有任何测量的情况下优化是徒劳的。

Donald Knuth 说:

我们应该忘记小效率,比如说97%的时间:过早的优化是万恶之源。

这取决于你所看到的“优化”。微观优化不应在早期阶段进行,只有在有正当理由(例如,探查器结果或类似结果)的情况下才应在后期进行。

然而,按照最佳实践和常见的编码准则编写结构良好、干净的代码是一个好习惯,一旦习惯了它,就不会比编写草率的代码花费更多的时间。这种“优化”(不是正确的词,但有些人认为是这样)应该从一开始就完成。

见 http://en.wikipedia.org/wiki/Program_optimization 供Knuth引用。

如果您认为优化可能会使您的代码难以(a)首先正确执行,或(b)长期维护,那么最好是先正确执行。拥有良好的开发过程,例如测试驱动的开发,可以帮助您稍后进行优化。

总是让它正确、缓慢地工作,而不是错误、快速地工作。

DonaldKnuth说得对,“过早的优化是万恶之源”,这会使你的编码速度变慢。优化的最佳方法是再次访问代码库并重构。这样,您就可以知道代码的哪个部分经常被使用,或者是一个瓶颈,并且应该进行微调。

过早的优化不是一件好事。 这对于低级别的优化尤其重要。但在更高的层次上,您的设计不应该锁定任何未来的优化。

例如。

集合的检索应该隐藏在方法调用之后,最终您可以决定是否缓存集合的检索。 当你有一个稳定的应用程序和!!)您已经开发了回归单元测试。您可以分析应用程序并优化热点。记住,在每一个优化步骤之后,您都应该运行完整的单元测试集。

在最初的编码过程中遵循优化技术是一个好的实践,还是应该首先只关注功能的实现?

如果您知道性能是关键的(或重要的),请在设计中考虑它,并在第一次正确地编写它。如果你在设计中没有考虑到这一点,这很重要,那么你就是在浪费时间或者“开发概念验证”。

其中一部分归结为经验;如果您知道优化和程序的问题领域,或者在过去已经实现了类似的功能,那么您的经验一定会帮助您第一次创建一个更接近最终结果的实现。如果您仍然需要概念验证,那么在完成之前不应该编写实际的程序——启动一些测试来确定什么解决方案适合这个问题,然后正确地实现它。

如果在最初的编码过程中只关注功能,那么在以后处理优化有多容易或有多困难?

有些修复很快,有些需要完全重写。事实发生后,越需要改变和适应,您就越浪费重新测试和维护一个执行得不好的程序的时间。最容易维护和维持需求的库通常是工程师了解理想设计的库,并在初始实现期间努力满足理想的库。

当然,这也假设你喜欢一个长期存在的程序!

过早的优化是万恶之源。

为了更详细地阐述这句名言,及早进行优化有利于分散你做一个好设计的注意力。而且,程序员在发现代码的哪些部分会带来更多的麻烦方面也非常糟糕,因此,尽量优化那些不那么重要的部分。您应该始终首先进行测量,以找出需要优化的内容,而这只能在后面的阶段中发生。