performance - 什么时候优化真的值得花时间在它上面？

Question

在我的 last question 之后，我想了解优化何时真正值得开发人员花时间在它上面。

花费 4 个小时让查询速度提高 20% 是否值得？是的，不，也许，是的，如果……？

'浪费' 7 小时将任务切换到另一种语言以节省大约 40% 的 CPU 使用率'值得'吗？

我对一个新项目的正常迭代是:

了解客户想要什么，需要什么；

计划项目:什么语言，在哪里，数据库设计；

开发项目；

测试和错误修复；

运行项目的最终分析和最终优化；

如果项目需要，进一步分析资源的实际使用情况，然后进一步优化；

暗示“写出好的、可维护的代码”。

显然，最大的“优化”部分发生在第 2 点，但通常在项目结束后查看代码时，我会发现一些部分，即使他们做得很好，也可以改进。这是第 5 点的基本原理。

举一个关于最后一点的具体例子，一个简单的例子是当我预计 90% 的查询是 SELECT 时。 10% 为 INSERT/UPDATE ，所以我对带有索引的数据库表收费。但是 6 个月后，我看到现实生活中有 10% SELECT查询和 90% INSERT/UPDATE s，所以查询速度没有优化。这是我想到的第一个例子(显然，这更像是对初始错误设计的“补丁”，而不是优化；)。

请注意，我是一名开发人员，而不是一名商人——但我希望保持良心，尽可能为我的客户提供最好的服务。

我的意思是，我知道如果我失去 50 个小时来获得应用程序总加速的 5%，并且该应用程序被 10 个用户使用，那么它可能不值得花时间......但是什么时候它是?

您认为优化何时至关重要？

您通常使用什么公式，意识到优化所花费的时间(和最终 yield )并不总是可以在纸上量化？

编辑 :对不起，但我不能接受像“直到人们不提示 id，不需要优化”这样的答案；它可以是商业观点(有问题，恕我直言)，但不是开发人员或(恕我直言)一个明智的答案。我知道，这个问题真的很主观。

我同意 Cheeso 的观点，性能优化应该推迟，在对项目的实际使用和负载进行一些分析之后，但可以在项目结束后立即进行一个小的'n'quick 优化。

谢谢大家 ;)

Answer 1

YAGNI .除非人们提示，否则很多。

编辑 :我建立了一个库，比那里的替代品要慢一些。它仍在获得使用和分享，因为它更好用且更强大。我继续投资于特性和功能，推迟任何有关性能的工作。

在某些时候，有足够多的功能和性能出现在列表的顶部，我终于花了一些时间来改进性能，但只是在考虑了很长时间的努力之后。

我认为这是处理它的正确方法。