过早优化_当过早的优化不是

过早优化

本月初，在听到多个开发人员使用此口头禅作为未在同一周做出更好决定的借口后，我决定写一篇关于并非所有优化都是过早优化的文章。 Bozhidar Bozhanov在他的文章《 并非所有优化都 为时过早》中击败了我，它提出了一些极好的但与我计划不同的观点，即假定如果不损害可读性或可维护性并花费时间，那么在早期优化中就没有错。可以忽略不计。”

Bozhanov的帖子提醒我，我想写这篇文章。 我使用这篇文章来提供其他示例和支持，以支持我的主张，即我们社区中的太多人已经允许“避免过早优化”成为“ 大头贴实践” 。 在我看来，一些开发人员已经采取了适当的建议来避免“过早优化”，或者不想花费时间和精力来真正考虑此语句背后的原因。 盲目地将其应用于所有情况似乎更容易，但这与过早优化一样危险。

好的设计不是过早的优化

我喜欢Rod Johnson在他的《 专家一对一J2EE设计和开发》 （2002） 一书中对 “设计”和“代码优化”之间的区别。 也许我看到开发人员在“避免过早优化”的幌子下做出错误决定的最常见情况是做出错误的体系结构或设计选择 。 本月初的事件促使我想写这篇文章，是开发人员断言，我们不应该将服务设计得比他想要的更粗糙，因为这是过早的优化，而他对同一服务进行多次连续调用的想法是“最容易”实施。 在我看来，该开发人员误以为没有过早优化代码的正确警告是没有考虑适当设计的借口，而这种设计可能几乎不需要花费额外的精力。

Johnson在设计与代码优化之间的区分中强调：“通过解决设计质量高的问题，最大限度地减少对优化的需求。” 在同一部分中，他警告“代码优化”的主要原因有四个：“优化很难”（“编程中的几件事比优化现有代码更难”），“大多数优化是没有意义的”，“优化会导致许多错误”。和“不适当的优化可能会永远降低可维护性。” 约翰逊指出（我同意），“在性能设计和可维护性之间没有冲突，但是优化可能会遇到更多问题。”

应用适当的语言实践不是过早的优化

我熟悉的大多数编程语言通常都提供多种方法来完成同一件事。 在许多情况下，替代方案之一具有众所周知的优势。 在这种情况下，使用性能更好的替代方案是否真的过早优化？ 例如，如果我正在编写Java代码以在循环中将字符追加到 String上 ，为什么我会使用Java String而不是StringBuilder进行此操作 ？ 就算是相对较新的Java开发人员， StringBuilder使用在可维护性或可读性方面也没有太大不同，并且存在已知的性能优势，无需进行分析即可识别。 以“避免过早优化”的名义用String编写它，并且仅在探查器显示它是性能问题时才将其更改为StringBuilder ，这似乎很愚蠢。 话虽如此，使用StringBuilder进行循环外的简单串联同样愚蠢，以防万一代码曾被放置在循环内。

同样，只要有条件的写不会首先使最有可能遇到的条件出现，这也不是“过早的优化”。 另一个例子是短路评估在有条件的情况下的普遍使用，而无需过早的优化就可以有效。 最后，在某些情况下，对于给定操作或一组预期操作， 某些数据结构或集合比其他数据结构或集合更合适。

编写更干净的代码不是过早的优化

一些开发人员可能会将更“高效”（更干净）的源代码与过早的优化混淆。 优化源代码的可读性和可维护性（例如在重构或精心设计原始代码中）与Knuth的原始报价无关。 编写更干净的代码通常可以提高性能，但这并不意味着编写更干净的代码是过早优化的一种形式。

其他人对过早优化的误解

除了“ 并非所有优化都是过早的”帖子外 ，有关误用“避免过早优化” 口头禅的其他帖子还包括乔·达菲（Joe Duffy） 的“过早优化是邪恶的”神话和“避免过早优化”并不意味着“写哑巴代码” 。

Duffy说得很好，我在这里直接引用他：

我听说过“过早的优化是万恶之源”的说法，程序员在软件生命周期的每个阶段都有不同的经验，用以捍卫各种选择，包括不良的体系结构，免费的内存分配以及不恰当的选择。数据结构和算法，以完全忽略对延迟敏感的情况下的可变延迟。 大多数情况下，这种玩笑被用来捍卫草率的决策，或证明决策的无限期推迟。 换句话说，懒惰。

James Hague的帖子指出了可能进入过早优化的迹象之一：“警告信号是当您开始追求清晰度和可靠性而又追求一些模糊的性能概念时。” 海格还写道：“在这些讨论中经常遗漏的是，“避免过早优化”的建议与“编写哑代码”不是同一回事。” 我喜欢最后一句话，因为我相信就像一些开发人员将敏捷概念掺入“对他们”意味着“ 没有文档 ”一样，一些开发人员也将合理的建议掺入 “避免过早优化”以“盲目地”对待（对他们）。写代码。”

过早优化是一个现实问题

过早的优化是开发人员必须提防的问题。 正如约翰逊在先前引用的书中指出的那样：“编程中几乎没有什么比优化现有代码更难的了。 不幸的是，这就是为什么优化能够满足任何程序员的自我的原因。 问题在于，用于这种优化的资源很可能被浪费了。” 这里有一些例子，说明过早的优化会浪费大量资源，甚至在某些情况下会使性能更差。 广受赞誉的克努斯（Knuth）写道：“过早的优化是万恶之源，这确实是有原因的。” 我并不是说过早的优化不存在或没有危害。 我只是说避免这种公认的功能失调的行为通常是避免思考或避免做出明智决定的借口。

结论

就像汽车上的保险杠贴纸天真地将复杂的问题归结为一些聪明而引人入胜的话一样，“避免过早优化”的使用通常比预期的要广泛得多。 如果不正确地应用推荐的最佳实践，甚至可能导致弊大于利，滥用“避免过早优化”就是最好的例子之一。 我已经看到过高的可维护性，可读性，甚至在性能上付出了高昂的代价，因为所谓的“优化”实施得太早，而牺牲了可读性和可维护性却没有可衡量的好处。 但是，盲目地使用“避免过早优化”作为避免设计和编写性能更好的软件的借口可能会导致同样高的成本。 “避免过早的优化”不是停止思考的借口。

参考： 当我们不是 JCG合作伙伴 Dustin Marx提出过早优化时， 来自Inspired by Actual Events博客。

翻译自: https://www.javacodegeeks.com/2012/11/when-premature-optimization-isnt.html

过早优化