On 'premature optimization'

Premature optimization is the root of all evil.
– Donald Knuth, 1974

Optimization is based on actual business needs , In procedure , Work hard on architecture and deployment , Reduce resource consumption , Improve the efficiency of resource utilization . Effective optimization can save energy and increase efficiency for enterprises , The boss changed Rolls Royce , The magic weapon of purchasing villas , It is programmers who improve themselves , The key to transforming yourself . We advocate optimization , But we should not optimize it too early . We don't deny optimization , Instead, it emphasizes that according to the actual business needs , Achieve timely and appropriate optimization .

There is still a feeling of premature optimization in the modern R & D process . Premature optimization is something developers should always consider , It is something that should be avoided in daily work .

A typical example is a startup company that spends a lot of time trying to figure out how to expand its software to meet millions of users . This is a problem worth considering , But it doesn't have to be done . Before worrying about dealing with millions of users , You need to make sure 100 Users like and want to use your product . You need to verify user feedback first .

Many times, we will optimize too early because we don't distinguish the primary contradiction from the secondary contradiction . In the above example , Mining user needs and improving user experience is obviously in line with the current priority . Performance optimization is important , But it may be something you need to consider in the next few years .

And experience is very important , But we must proceed from reality . From the actual budget and resources , Choose a framework based on experience , Staffing , Resource allocation . Put an end to it ‘ This is how my last company realized ’. First of all, we should realize that the river we crossed today is not the same as the river we crossed yesterday , At least the sand under your feet is different . This feeling is like making you wear other people's clothes as awkward .

Netease cloud may not have thought of it at the beginning , Netease cloud fire is not songs , It's the comments inside . Before we get the feedback from the market, don't take it for granted to increase the horsepower in advance to optimize what you think . The market will let you know what is ‘ Don't you think , I want me to feel ’.

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

Programmers waste a lot of time thinking 、 Worry about the performance of non critical parts of the program , If you consider the overall code Of debug And maintenance time , Then the cost of these performance optimization is not worth the loss . For about 97% Small optimization of spot , We should ignore them ： Premature optimization why the root of all evil . And for the rest of the key 3%, I We cannot give up the opportunity of optimization .

How should we do

1. Make it work.
2. Make it right (the code is readable [uses IntentionRevealingNames] and every idea is expressed OnceAndOnlyOnce).
3. Make everything work.
4. Make everything right.
5. Use the system and find performance bottlenecks.
6. Use a profiler in those bottlenecks to determine what needs to be optimized. See ProfileBeforeOptimizing.
7. Make it fast. You maintained unit tests, right? Then you can refactor the code mercilessly in order to improve the
   -performance.

1. Let it work .
2. Make it right （ The code is readable [ Use IntentionRevealingNames ], Every idea is expressed as OnceAndOnlyOnce）.
3. Let everything work .
4. Do everything well .
5. Use the system and identify performance bottlenecks .
6. Use analyzers in these bottlenecks to determine what needs to be optimized . see also ProfileBeforeOptimizing.
7. hurry up . You maintained unit tests , Right ？ Then you can ruthlessly refactor the code to improve performance .
																	—— Guillermoschwatts 

Before getting market feedback , Everything is based on empirical assumptions , Excessive optimization will greatly increase the cost of this assumption . Making assumptions right is the essence of optimization