为什么过早的优化是万恶之源

为什么过早的优化是万恶之源?

缘起

Donald Knuth（高德纳） 是一位计算机科学界的著名学者和计算机程序设计的先驱之一。他被誉为 计算机科学的“圣经”《计算机程序设计艺术》的作者 ，提出了著名的“大O符号”来描述算法的时间复杂度和空间复杂度，开发了TeX系统用于排版科技文献，获得过图灵奖、冯·诺伊曼奖、美国国家科学奖章等多项荣誉。今天要说的就是他所提出的一条 软件设计重要原则 Premature optimization is the root of all evil 过早优化是万恶之源。

为什么说“过早优化是万恶之源”？

我认为过早优化代码会让人陷入到错误的目标中去，从而忽视掉了最重要的目标。举个很简单的例子， 你需要快速构建一个产品来抢占用户，你当下最重要的目标是让这个产品快速上线 ，而不是把这个产品打造的好用(在中国互联网下，这样的事数不胜数)， 如果你只关注到后者体验、性能问题而忽视了速度，在当下高度竞争的市场之下，你根本毫无机会。

当然上面这个例子是从感性的层面说的，对很多程序猿来说也可能涉及不到产品层面的内容。我们从软件设计的层面，理性的来说，过早优化可能会导致以下的一些问题：

1. 增加代码的复杂性 ：过度优化可能会导致代码的复杂性增加，从而降低代码的可读性和可维护性。如果代码过于复杂，可能会导致开发人员难以理解和维护代码，从而增加开发成本和时间。
2. 耗费开发时间和资源 ：过度优化可能会导致开发人员花费大量时间和资源在代码的性能优化上，而忽略了其他重要的开发任务。这可能会导致项目进度延误和开发成本增加。
3. 降低代码的可移植性 ：过度优化可能会导致代码的可移植性降低。如果代码过于依赖于特定的硬件或操作系统，可能会导致代码无法在其他环境中运行。
4. 降低代码的可扩展性 ：过度优化可能会降低代码的可扩展性。如果代码过于依赖于特定的算法或数据结构，可能会导致代码无法适应未来的需求变化。

过早优化的典型案例

在软件工程史上由于过度关注软件性能导致项目最终失败的案例比比皆是，比如我下面要说的一些项目，在软件工程史上都是非常知名的项目（当然可能有些新生代程序员已经不知道了）。

1. IBM OS/360操作系统 ：在20世纪60年代，IBM公司开发了OS/360操作系统，这是当时最大的软件工程项目之一。在开发过程中，IBM公司过于关注代码的性能问题，导致代码的复杂性增加，开发时间延误，最终导致项目的失败。我知晓这个项目还是在我最近在阅读的一本软件工程经典书籍《人月神话》中，也推荐大家阅读下，这个项目虽然最终失败了，但也给整个软件工程领域留下了宝贵的经验。
2. Netscape Navigator浏览器 ：在20世纪90年代，Netscape公司开发了Navigator浏览器，这是当时最流行的浏览器之一。在开发过程中，Netscape公司过于关注代码的性能问题，导致代码的复杂性增加，开发时间延误，最终导致浏览器市场份额严重下降。
3. Windows Vista操作系统 ：在21世纪初，微软公司开发了Windows Vista操作系统，这是当时最大的软件工程项目之一。在开发过程中，微软公司过于关注代码的性能问题，导致代码的复杂性增加，开发时间延误，最终导致操作系统的用户体验不佳，市场反响不佳。话说这个操作系统我还用过呢，用户界面还是很漂亮的，很多UI设计也被沿用到了Window7中。

如何识别过早优化

在软件开发过程中，如何判断是否过早优化呢？这里有一些概括性的判断标准，可以简单参考下：

1. 是否存在性能问题： 如果代码还没有性能问题，那么过早优化就是不必要的。因此，在进行优化之前，应该先测试代码的性能，确定是否存在性能问题。
2. 是否优化了未来可能发生的问题 ：如果优化的是未来可能发生的问题，而不是当前存在的问题，那么就可能是过早优化。在进行优化之前，应该优先考虑当前存在的问题，而不是未来可能发生的问题。
3. 是否牺牲了代码的可读性和可维护性 ：如果优化代码会导致代码的复杂性增加，降低代码的可读性和可维护性，那么就可能是过早优化。在进行优化之前，应该优先考虑代码的可读性、可维护性和可扩展性。
4. 是否浪费了大量的开发时间和资源 ：如果优化代码会浪费大量的开发时间和资源，而不是提高代码的性能和效率，那么就可能是过早优化。在进行优化之前，应该评估优化的成本和收益，确定是否值得进行优化。

判断是否过早优化需要根据具体情况进行评估。 在进行优化之前，应该先测试代码的性能，确定是否存在性能问题。同时，也应该优先考虑代码的可读性、可维护性和可扩展性，避免过度优化。

总结

作为一名在IT领域摸爬滚打多年的工程师，我深有体会地认识到过早优化是软件开发中的一大陷阱。在软件开发的初期，我们可能会过于关注代码的性能问题，而忽略了代码的可读性、可维护性和可扩展性。这种做法可能会导致代码的复杂性增加，降低代码的可读性和可维护性，甚至可能会浪费大量的开发时间和资源。

在软件开发过程中，我们应该避免过早优化，而是优先考虑代码的可读性、可维护性和可扩展性。当需要进行性能优化时，应该在代码的基础上进行优化，通过分析性能瓶颈、优化算法和数据结构等方法来提高代码的性能和效率。同时，我们也应该意识到， 性能优化并不是软件开发的唯一目标，我们还应该注重代码的可读性、可维护性和可扩展性，以便保证代码的质量和可靠性。

拓展

代码优化的好处多多，但是这并不意味着所有的代码都需要进行优化，有时过度的优化反而适得其反——费时、费力、不讨好。

“现代计算机科学的鼻祖”Donald Knuth曾说过“过早的优化是万恶之源”，因为：让正确的程序更快，要比让快速的程序正确容易得多。

在项目开发中，总是有程序员浪费宝贵的时间去改进那些不需要改进的代码，而没有通过所做的改进增加价值。在对项目进行优化时，究竟哪些地方应该优化，应该如何优化，哪些不应该优化呢？你需要先来了解一下本文所说的这7件事。

1. 究竟要优化什么？

在优化工作开始的时候，你还尚未明确优化内容和目的，那么你很容易陷入误区。在一开始，你就应该清楚地了解你要达到的效果，以及其他优化相关的各种问题。这些目标需要明确指出（至少精通技术的项目经理可以理解和表达它），接下来，在整个优化过程中，你需要坚持这些目标。

在实际的项目开发中，经常会存在各种各样的变数。可能一开始时要优化这一方面，随后你可能会发现需要优化另一方面。这种情况下，你需要清晰地了解这些变化，并确保团队中的每个人都明白目标已经发生了变化。

2. 选择一个正确的优化指标

选择正确的指标，是优化的一个重要组成部分，你需要按照这些指标来测量优化工作的进展情况。如果指标选择不恰当，或者完全错误，你所做的努力有可能白费了。

即使指标正确，也必须有一些辨别。在某些情况下，将最多的努力投入到运行消耗时间最多的那部分代码中，这是实用的策略。但也要记住，Unix/Linux内核的大部分时间花费在了空循环上。

需要注意的是，如果你轻易选择了一个很容易达到的指标，这作用不大，因为没有真正解决问题。你有必要选择一个更复杂的、更接近你的目标的指标。

3. 优化在刀刃上

这是有效优化的关键。找到项目中与你的目标（性能、资源或其他）相背的地方，并将你的努力和时间用在那里。

举一个典型的例子，一个Web项目速度比较慢，开发者在优化时将大部分精力放在了数据库优化上，最终发现真正的问题是网络连接慢。

另外，不要分心于容易实现的问题。这些问题尽管很容易解决，但可能不是必要的，或与你的目标不相符。容易优化并不意味着值得你花费工夫。

4. 优化层次越高越好

在一般情况下，优化的层次越高，就会越有效。根据这个标准，最好的优化是找到一个更有效的算法。

举个例子，在一个软件开发项目中，有一个重要的应用程序性能较差，于是开发团队开始着手优化，但性能并没有提升太多，之后，项目人员交替，新的开发人员在检查代码时发现，性能问题的核心是由于在表中使用了冒泡排序算法，导致成千上万项的增加。

尽管如此，高层次的优化也不是“银弹”。一些基本技术，如将所有东西移到循环语句外，也可以产生一些优化的效果。通常情况下，大量低层次的优化可以产生等同于一个高层次优化的效果。

还需要注意的是，高层次优化，会减少一些代码块，那么你之前对这些代码块所做的优化就没有任何意义了，因此，刚开始就应该考虑高层次的优化。

5. 不要过早优化

在项目早期就进行优化，会导致你的代码难以阅读，或者会影响运行。另一方面，在项目后期，你可能会发现之前所做的优化没有起到任何作用，白白浪费了时间和精力。

正确的方式是，你应该将项目开发和优化当作两个独立的步骤来做。

6. 依赖性能分析，而不是直觉

你往往会认为你已经知道哪里需要优化，这是不可取的，尤其是在复杂的软件系统中，性能分析数据应该是第一位的，最后才是直觉。

优化的一个有效的策略是，你要根据所做工作对优化效果的影响来进行排序。在开始工作之前找到影响最大的“路障”，然后再处理小的“路障”。

7. 优化不是万金油

优化最重要的规则之一是，你无法优化一切，甚至无法同时优化两个问题。比如，优化了速度，可能会增加资源利用；优化了存储的利用率，可能会使其他地方放慢。你需要权衡一下，哪个更符合你的优化目标。