如何处理关于“过早优化是万恶之源”的误解？

我遇到了很多人，他们在原则上反对任何在英语中通常被认为是“优化”的东西，他们经常逐字引用（部分）引用“过早的优化是万恶之源”。作为他们立场的理由，暗示他们将我所说的一切解释为“过早的优化”。但是，这些视图有时是如此可笑地根深蒂固，以至于它们几乎消除了任何与最纯粹的“天真的”实现方式有关的算法或数据结构偏差……或者至少与它们之前的工作方式无关。在听到“性能”或“优化”的消息后，人们如何才能像这样使人们再次“张开耳朵”？我该如何讨论对性能有影响的设计/实现主题，而又不会让人立即想到：“这个人想花两周时间来编写十行代码？”

现在，在这里以及在Web的其他角落已经讨论了 “是否所有优化都是过早的并因此有害的”的立场，并且已经讨论了如何识别优化何时过早并因此有害的立场，但是不幸的是，现实世界中仍有一些人不愿意挑战自己对反优化的信念。

以前的尝试

几次，我试图提供Donald Knuth的完整报价，以解释“过早的优化是不好的”↛“所有的优化都是不好的”：

我们应该忘记效率低下的问题，例如大约97％的时间：过早的优化是万恶之源。然而，我们不应放弃我们那临界的3％的机会。

但是，在提供完整报价时，这些人有时有时会变得更加确信我在做的是Premature Optimization™，并深入研究并拒绝听。好像“优化”一词使他们感到害怕：在某些情况下，我能够通过避免使用“优化（e | ation）”一词来提出实际的性能改进代码更改，而不会被否决。和“性能”（这个词也很吓人），而是使用“替代架构”或“改进的实现”之类的表达方式。因此，这似乎真的是教条主义，而不是他们实际上是对我的批评进行评估，然后视其为不必要和/或过于昂贵而将其驳回。

看来您正在寻找捷径，而不是先尝试“最纯真的实现”，而直接实现“更复杂的解决方案，因为您事先知道纯朴的实现不会这样做”。不幸的是，这很少能奏效—当您没有确凿的事实或技术论据来证明天真的实现太慢或太慢时，您很可能错了，而您正在做的是过早的优化。试图与Knuth争论与事实不符。

以我的经验，您要么不得不硬着头皮先尝试“天真的实现”（并且可能会惊讶地发现这样做足够快），或者至少会对运行时间做出粗略的估计，例如：

“天真的实现将是O（n³），并且n大于100.000；它将运行几天，而天真的实现将在O（n）中运行，这只需要几分钟。”

只有掌握了此类论据，您才能确定优化还不成熟。

恕我直言，只有一个例外：当更快的解决方案也是更简单，更干净的解决方案时，则应从一开始就使用更快的解决方案。标准示例是使用字典而不是列表以避免不必要的循环代码进行查找的方法，或者使用良好的SQL查询来提供恰好您需要的一个结果记录，而不是必须使用较大的结果集。之后在代码中过滤。如果遇到这种情况，请不要争论绩效-表演可能会带来额外的好处，但最有可能是无关紧要的，当您提到它时，人们可能会倾向于使用Knuth来对付您。关于可读性，较短的代码，更简洁的代码，可维护性的争论–这里不需要“掩盖”任何东西，而是因为这里的（和仅那些）是正确的参数。

以我的经验，后一种情况很少见-更典型的情况是，首先可以实现一种简单，幼稚的解决方案，与更复杂但可能更快的解决方案相比，这种解决方案更易于理解且不易出错。

当然，您应该充分了解需求和用例，以了解可接受的性能，以及在用户眼中什么时候变得“太慢”。在理想的情况下，您会得到客户的正式性能规格，但是在现实世界的项目中，所需的性能通常是一个灰色区域，只有当用户注意到程序在生产中表现为“太慢”时，用户才会告诉您。通常，这是找出某件事太慢的唯一方法，即用户反馈，然后您无需引用Knuth就能说服您的队友“天真的实现”还不够。

问问自己：

• 该软件是否不符合性能规格？
• 该软件是否存在性能问题？

这些是要优化的原因。因此，如果有人反对，只需向他们展示规格并返回给他们，并解释说我们需要优化，因为我们不符合规格。除此之外，一个人很难说服其他人优化是必要的。

我认为报价的重点是，如果您没有问题，请不要执行不必要的优化，因为时间和精力可能会花在其他地方。从业务前景来看，这是完全合理的。

第二，对于那些担心优化的人，总是用指标来备份性能结果。代码快多少？与以前相比，性能提高了多少？如果一个人只花了两周时间就将代码比以前的版本提高了2％，那么如果我是你的老板，我将不会高兴。那两个星期本可以花在实施一项新功能上，以吸引更多的客户并赚更多的钱。

最后，大多数软件不必进行高度优化。只有在少数几个专业行业中，速度才真正重要。因此，大多数情况下，可以使用预先存在的库和框架来取得良好的效果。

在讨论与绩效息息相关的那一刻如何与之打交道？

从建立在团队战略方向上的共同原则开始。

我的原则：

我写代码的个人原则是，首先要确保程序的正确性，然后对其进行概要分析并确定是否需要优化。我自己分析我的代码，因为其他程序员是我代码的潜在使用者-如果速度太慢，他们将不会使用它-因此，对于我的代码而言，速度是一项功能。

如果您的消费者是客户，那么您的客户会告诉您是否需要更快的代码。

但是，人们可以在代码中找到已知的，明显更好的选择。由于以下几个原因，我宁愿在第一稿中做到正确：

1. 如果我第一次做对了，那么我可以忘记实现（利用信息隐藏的优势），而且我不会用TODO弄乱我的代码。
2. 其他人（尤其是那些只在工作中学习的人）认为它做得正确，并且他们会学习并使用相同的代码风格。相反，如果他们看到我做错了方法，他们也会做错了方法。

假设优化需求是正确的

假设这是需要优化的代码中真正重要的部分，您可以将Schlemiel的寓言告诉Painter，或者强调引号的其余部分：

“程序员浪费大量时间来思考或担心程序非关键部分的速度，而在考虑调试和维护时，这些对效率的尝试实际上会产生严重的负面影响。我们应该忘记效率低下， 97％的时间：过早的优化是万恶之源，但我们不应该在这3％的临界风险中放弃机会。” -唐纳德​​·努斯

权衡额外复杂性的成本

有时，就增加的复杂性的可维护性而言，确实要付出一定的代价。在这种情况下，您可以将辅助实现保留在不同的函数或子类中，并对其应用相同的单元测试，以便毫无疑问它是正确的。以后，如果您对代码进行概要分析并发现简单的实现会成为瓶颈，则可以切换优化的代码并明显改善程序。

领导

有时候问题出在自我上-有些人宁愿使用次优或错误的代码，也不希望别人比自己更正确。您可能想避免与这些人一起工作。

领导力，尤其是当您没有对人的职位权限时，是关于提出合理的建议并指导他人达成共识。如果您不能引导您的团队进行讨论，那么此事就不值得紧迫地解决。可能有更大的鱼要炸。

前进的道路是忘记实际的报价和各种解释-教条主义要么集中于一位大师的特定报价，要么就任教。谁说Knuth总是对的？

而是专注于手头的项目，您正在开发的软件以及您不同意的同事。对于此软件可接受的性能有什么要求？比这慢吗？然后优化。

您不必将其称为“优化”，而可以将其称为“修复错误”，因为根据定义，如果实现不符合要求，它就是错误。

更一般而言，有两种关于优化的可能性：

1. 优化的代码也更短，更易于理解和维护。

2. 优化的代码更难理解，花费更长的时间编写和测试，或者如果需求以意想不到的方式改变，将来的更改也将更加复杂。

如果情况是（1），则您甚至不必争论优化问题。但是，如果（2）是这种情况，那么您正在权衡决策。这实际上是业务级别的决定，而不仅仅是技术决定。您必须权衡优化成本与收益。为了获得更大的收益，效率低下首先要成为问题，要么是糟糕的用户体验，要么是硬件或其他资源的成本显着增加。

我认为上下文中的完整引用是有启发性的。我将从我在Reddit上发表的有关该主题的帖子中复制：

毫无疑问，效率的圣杯会导致滥用。程序员浪费大量时间来考虑或担心程序非关键部分的速度，而在考虑调试和维护时，这些提高效率的尝试实际上会产生严重的负面影响。我们应该忘记效率低下的问题，例如大约97％的时间：过早的优化是万恶之源。

然而，我们不应放弃我们那临界的3％的机会。优秀的程序员不会因这种推理而沾沾自喜，他应该明智地仔细看待关键代码。但只有在识别出该代码之后。

-Donald Knuth，“ 转到语句的结构化编程”， ACM计算调查，1974年12月，第6卷，第4期，第268页

重点是，与过早地关注优化相比，还有更多重要的事情要担心。当然，您应该仔细考虑数据结构和算法（在3％之内），但不必担心减法是否比模数更快（在97％之内），直到可以清楚地看到低级优化是必要。

前者不一定在您的同事正在思考的意义上进行优化，而是在选择错误的算法和数据结构不是最佳的意义上进行优化。

以我的经验，如果您经常遇到这种对优化的反对，那么人们就不会真正抱怨优化。他们抱怨您以优化的名义牺牲了什么。这通常是可读性，可维护性或及时性。如果您的代码在相同的时间内交付并且很容易理解，那么如果您使用的是更高效的数据结构和算法，人们将不会在乎。在这种情况下，我的建议是努力使您的代码更加优雅和可维护。

如果您在反对他人代码方面遇到这种反对，通常是因为您建议进行大量返工。在这些情况下，您确实确实需要一些实际的测量来证明这是值得的，或者可能在编写代码之前尝试尽早参与设计阶段。换句话说，您需要证明它在3％之内。如果我们重写了不完全符合我们要求的所有代码，我们将永远无法完成任何工作。

关于此报价确实存在很多误解，所以最好退后一步，看看实际的问题是什么。问题不在于您永远不应该“优化”。这就是“优化”绝不是您应该着手完成的任务。您永远不要在早晨醒来，对自己说：“嘿，我今天应该优化代码！”。

这导致浪费精力。只是看代码并说“我可以使其更快！” 导致付出大量努力使某些事情变得更快，而这些事情首先就足够快了。您可能会感到自豪，因为告诉自己您编写代码的速度提高了四倍，但是如果该代码是在按下按钮时进行的计算，并且在向人类用户显示之前首先花费了10毫秒的时间，该死的

那就是“过早优化”中的“过早”。什么时候不是“过早的”？当客户告诉您“这太慢了，请解决它！” 那是您挖掘代码并尝试使其更快的时候。

这并不意味着您应该关闭大脑。这并不意味着您应该在单个链接列表中保留10,000个客户记录。您应该始终了解自己所做的工作对性能的影响，并采取相应的措施。但您的想法是，您不必故意花额外的时间来尝试使其更快。您只是从其他选择中选择性能更高的选择。

您可以以错误的方式进行操作，也可以以正确的方式进行操作。

通常，事情以错误的方式进行，代码被重构，从而以正确的方式进行。如果您要编写新代码，并且知道可以正确地做事而不会受到重大损失，那么我会错误地以正确的方式做事。（请注意，在性能测试等之后，可能需要进行一些更改-没关系。或者，完全天真的实现很少（如果有的话）是对的。）

如果您a）知道将来会有所帮助，或者b）知道次优路径会导致问题，那并不一定是过早的优化。真的，这就像下棋游戏。

我认为人们倾向于做正确的事情，而不是做错事情。与同事讨论替代策略时，请使用此选项。

这似乎是通信问题，而不是编程问题。尝试理解人们为什么会感觉自己的方式，并试图明确为什么您认为自己的方式会更好。完成此操作后，请勿提出对抗性争论，而争论的目的是告诉别人他们为什么错了而你正确了。说明您的想法和感受，并让人们对此有所反应。如果您无法达成任何共识，并且您认为这是一个非常关键的问题，那么整个团队可能就存在一些严重的问题。

更专注于实际编程，不要将时间浪费在长篇大论的争论上，而只是觉得自己“更快”。如果您看到有人编写一个在Web应用程序中每个请求调用一次的方法，并且当您知道它确实是O（log（n））时间问题时，它的时间复杂度为O（n ^ 2），那么可以肯定，如果这样的话毫无疑问，继续吧。

但是请注意，作为人类，我们的程序员在猜测应用程序的哪些部分会遇到瓶颈方面确实很糟糕（我的意思是AWFUL）。埃里克·利珀特（Eric Lippert）在此博客文章中撰写了有关这个有趣主题的文章。始终主张可维护性。当您有更多信息时，可以轻松地（相对地）解决最终发现的任何性能问题。