代码优化是一把双刃剑

为何优化并不总是一个好主意？

优化是对已经开始工作的单元进行改进的过程。对于终端用户或客户来说，这就像是樱桃一样诱人。出于同样的原因，代码优化在软件行业非常流行。但是优化代码真的总是有益的吗？我在软件行业已经工作五年多了，我可以告诉你的是，代码优化是一把双刃剑。如果处理不当，它可能弊大于利。

在软件术语中，我们使用术语“过早优化”来表示不好或不必要的优化。说起来容易做起来难，实际上，发现过早优化并不容易。在这篇文章中，我将与大家分享一些可以帮助你进行优化并避免代码过早优化的方法。

让我们开始吧。

万恶之源

代码优化是修改软件系统的过程，目的是使程序执行得更快，或使其能够在运行时使用更少的内存或其他资源。大多数开发人员相信代码优化是软件开发过程中必要的一步。但事实上并非如此。永远不要过早尝试优化应用程序的代码——或只在需要时才尝试优化代码。

过早优化是编程中的一切（或至少大部分）恶之根源。——唐纳德·克努斯

基于简洁的思想写成的源代码足以满足 99%情况下的性能需求。而且这将极大地提高应用程序的可维护性。

例子：

• 在 C 语言中使用指针运算代替数组符号，包括使用诸如以下风格的代码：

for (p = q; p < lim; p++)

• 在 Lua 中重新绑定全局变量到局部变量，例如：

local table, io, string, math= table, io, string, math

简而言之，如果一种技术使程序更难以理解，那么这就是过早优化。

过早优化的最大问题是，它可能会引入意料之外的 bug，并可能浪费大量资源和时间。

“毫无疑问，效率的圣杯导致了滥用。程序员浪费了大量的时间来考虑或担心他们程序非关键部分的速度，而这些提升效率的尝试实际上会对调试和维护产生强烈的负面影响。我们应该忘记那些小的效率提升，比如说 97%的情况下，过早优化是万恶之源。

然而，我们不应该错过这关键 3%的优化。一个好的程序员不会因为以上推理而沾沾自喜，他会明智地仔细审查关键代码，但必须是在这些关键代码被识别之后。”

— Structured Programming with go to Statements (1974)

为什么开发人员倾向于过早优化

人们往往在不知不觉中追求过早优化，这可能有多种原因，包括：

• 他们很容易花大量时间思考不重要的事情，以取得错误的进步感。

• 他们只是不知道如何提前计划，并弄清楚在开发过程的每个阶段他们应该从事哪些任务。

• 他们甚至会在开始尝试之前就规划好未来的行动方案，因为纸上谈兵总是更容易。

• 这代表了一种现象，即人们花费不成比例的资源来处理相对次要的问题。 

如何避免过早优化

在确定是否应该优化某些东西时，你应考虑一些因素，并问自己几个重要的问题。

以下这些问题可以帮助你决定是否值得这么做：

• 我们为什么要优化？

在此阶段是否真的有必要进行优化，或者您只是因为要避免处理其他问题而专注于此？

• 优化的好处是什么？

您应该有充分的理由来优化它，因为它将需要资源。它应该足以值得每个人花费时间，并且对项目有重大的影响。

• 优化的成本有多高？

实现优化需要多少团队努力和时间?这是否会影响项目正在进行中的工作流程?这类事情需要在执行之前进行评估。

• 优化的后果是什么？

这种优化在不久的将来会给您带来什么问题？会增加应用程序的测试范围吗？

在回答了所有这些重要问题并在团队中进行讨论之后，就可以决定是否需要优化了。

最后的想法

任何以性能为名使您的代码难以理解的编码实践都是不值得的。在没有可衡量的性能问题的情况下，您不应该进行优化，因为这是过早优化，就算你认为自己会获得性能上的提升也不要这样做。

像其他所有性能问题一样，你应该在开始任何优化之前都进行评估。

英文原文链接：

https://codeburst.io/code-optimization-is-like-a-double-edged-sword-86ba957386cf