Premature optimization is the root of all evil.
– Donald Knuth, 1974
优化即根据实际的业务需求,在程序,架构以及部署方面下功夫,降低资源消耗,提升资源利用效率。有效的优化能给企业节能增效,是老板换劳斯莱斯,加购别墅的制胜法宝,是编程人提升自我,改造自我的关键所在。我们推崇优化,但是不能过早优化。我们不否定优化,而是强调根据实际业务需求,做到适时适当的优化。
现代研发过程中仍然存在过早优化的情绪。过早优化是开发人员应该一直考虑的事情,是在日常工作中应该尽量避免的事情。
一个典型的例子是一家创业公司花费大量时间试图找出如何扩展其软件以满足数百万用户。 这是一个非常值得考虑的问题,但不一定要付诸行动。 在担心处理数百万用户之前,你需要确保100个用户喜欢并且想要使用你的产品。 需要首先验证用户反馈。
很多时候我们会过早优化是因为没分清主要矛盾与次要矛盾。在上述例子中,挖掘用户需求提升用户体验显然才是符合当前要务。性能优化重要,但可能是你未来几年时间需要考虑的事情。
还有就是经验很重要,但是得从实际出发。我们从实际的预算和资源,根据经验判断选择框架,人员安排,资源分配。杜绝出现‘我上家公司就是这么实现’。首先我们应该认识到今天趟过的河和跟昨天趟过的不是同一条河流,至少脚下的沙子不一样。这种感觉就像是让你穿上别人的衣服一样的别扭。
网易云可能当初也没想到,网易云火的不是歌曲,而是里面的评论。在我们还没有得到市场的反馈前不要理所当然的提前加大马力优化你认为的。市场会让你知道什么是‘不要你觉得,我要我觉得’。
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
PrematureOptimization程序员们浪费了大量的时间去思考、担心程序中非关键部分的性能,如果考虑整体代码 的 debug 和维护的时间,则这些性能优化的开销是得不偿失的。对于约 97% 的小优化 点,我们应该忽略它们:过早优化为什么万恶之源。而对于剩下的关键的 3%,我 们则不能放弃优化的机会。
我们应该如何做
- Make it work.
- Make it right (the code is readable [uses IntentionRevealingNames] and every idea is expressed OnceAndOnlyOnce).
- Make everything work.
- Make everything right.
- Use the system and find performance bottlenecks.
- Use a profiler in those bottlenecks to determine what needs to be optimized. See ProfileBeforeOptimizing.
- Make it fast. You maintained unit tests, right? Then you can refactor the code mercilessly in order to improve the
-performance.
1.让它起作用。
2.让它正确(代码是可读的[使用IntentionRevealingNames ],每个想法都表达为OnceAndOnlyOnce)。
3.让一切工作。
4.把一切都做好。
5.使用系统并找出性能瓶颈。
6.在这些瓶颈中使用分析器来确定需要优化的内容。请参阅ProfileBeforeOptimizing。
7.快一点。你维护了单元测试,对吧?然后你可以无情地重构代码以提高性能。
——吉列尔莫施瓦茨
在未得到市场反馈前,一切都是根据经验的假设,而过度的优化则会让这种假设的成本大大增加。让假设恰到好处正是优化的精髓所在