写然后优化或写优化

Question

你写你的代码然后优化它吗？还是从一开始就编写优化的代码。

我一直相信写作优化，因为我真的不喜欢重写代码，但请分享你的想法。

Answer 1

有一个简单的三阶规则：

1. 把它弄对。正确性是最重要的，快速或漂亮地做错事的东西是无用的。这必须比“哦，这似乎还行”更深入--它必须真正可靠地工作在您打算使用代码的整个应用领域。
2. 弄得漂亮点。代码的优雅和简单是很重要的。您在1下面编写的代码可能有几个类似于原型的属性。在这个阶段，您可能可以大幅减少代码的数量，使其简单得多，或者两者兼而有之。拥有易于理解、文档完整、优雅的代码，可以更容易地进入下一步。这里经常发生的情况是，您可能会发现一个算法优化，以解决同样的问题，同样正确。这些算法优化通常比非常低层次的优化更干净、更好、更有效.
3. 快拿来。现在您已经知道了它是如何工作的，它是如何工作的，并且已经有了详细的文档，您可以看看是否需要使它更快。通常你不会-见下面的弗洛里安回答。只有当您确实需要优化(使用分析器！)，您现在就这样做。你是从很好的代码开始的。如果你真的很努力地优化，你可能最终会得到不那么漂亮的神秘代码--但没关系，它已经被记录下来了，而且在你的VCS历史记录中也有一个漂亮的版本可以参考。

Answer 2

经验法则是这个(强调我的)：

程序员会浪费大量的时间来思考或担心程序中非关键部分的速度，而这些提高效率的尝试在考虑调试和维护时实际上会产生很大的负面影响。我们应该忘记小效率，说大约97%的时候:过早的优化是所有邪恶的根源。然而，我们不应在这个关键的3%中放弃我们的机会。-DonaldE.Knuth，“用go to语句进行结构化编程”

现在，这并不意味着您应该编写效率低下的代码。如果不需要比低效代码花费更多的时间，那么应该编写高效的代码。如果您可以执行一个SQL请求而不是100个SQL请求，请这样做。如果你不需要更多的时间，那就是。

这段代码可能不会经常被使用，所以它实际上根本不是一个瓶颈，尽管它可能看起来效率低下。如果以一种有效的方式写它意味着花费太多的时间，那么你的企业就没有任何附加价值。

当然，如果您必须优化一些东西，因为它是缓慢的，永远不要忘记首先配置文件。

一些你可能感兴趣的链接：

• 在分析之前进行优化总是错误的吗？
• 在编码时，微优化很重要吗？

Answer 3

你是建议做过早的优化吗？

当它符合性能非功能性要求时，代码是快速的。在满足这些需求之前，您不必关心性能:还有更重要的事情要关心，比如代码的质量、体系结构等等。

一旦非功能性性能需求被您的代码打破，这意味着它比可接受/需要的要慢。此时，您应该：

• 分析您的代码(而不是猜测瓶颈所在，因为我们总是搞错它)，
• 优化它，直到与需求相对应的测试再次通过。