Martial arts world, conquering, but not fast breaking! So we did not pay attention to the speed wrong!
The old saying: Do not premature optimization. I agree!
We are in the process of writing code, sometimes just to pursue the so-called performance, then gave himself pitted.
On the development of speed, I think the following points:
1. The running speed of thinking: not just for speed discarded: scalability, high cohesion, low coupling; also from a higher level to consider the issue, such as easy to understand, easy to maintain, layered architecture, extension;
2. Developing thinking speed: fast start is a good thing, but do not begin to think clearly before. Development did not move, a flow chart (sub-system) in advance;
Thinking 3. Product iteration speed: Prior uncertain thing, think again first product value, if you feel ok, then do it, but it must be fast. Rapid trial and error, quickly changed to allow a slight bug on the line, but must have a feedback mechanism; done quickly and orderly, more than a motor;
4. Thinking about performance tuning speed: performance optimization is a long-term thing was not to be done quickly, we wanted stability, repeated testing, repeated assessments, rollback mechanism, and then on the line;
Code rate:
1. Use to tangle if not switch, to tangle;
2. clarity in front of the code, a two nested do not care;
3. multiplying the need to move into position;
4. Use care agent;
The do not care necessary introduces a few dependencies;
6. Test several units do not care;
7. Several configuration variables do not care;
8. do not care to open up some background maintenance thread;
9. care due to the resulting polyethylene layer function calls;
10. The retractable do not care for the extra work;
11. care services due to split caused by network overhead;
12. A multi-layer package calls not care unified external;
13. Recommendation box: "effective java", "refactoring to improve the design of existing code."
Thoughts on the development of speed:
1. Do not blindly think fast;
2. System Architecture advance;
3. The architecture relies on existing needs and possible future development plans;
4. according to demand, good module division;
5. Each module make the appropriate flowchart (sub-system);
6. Before writing the actual code to write test cases, good results are expected;
7. Provide a unified and stable external interface as soon as possible, do not indulge internal logic;
8. place too late to change, marked todo label, to be somewhat stable external environment, and then come back quickly fix internal problems;
9. do unit testing;
10. observe the true test result, and whether there is an error, an outer black box test to see if the problem in the white box;
11. Finally, focus on performance;
12. Recommended books: "head first design patterns", "large sites Architecture Design"
Product iteration speed of thinking:
1. Locate the problem solved good, location good customer base;
2. problem-centered, concentrated focus, rapid on-line, market-proven;
3. Observe the results, as close to real users, identify problems and quick fixes;
4. follow the subsequent break point, rapid iteration;
5. Continue to observe the effect of the product, improved;
6. found subtle point, found that users of potential point, to solve their problems;
7. slow down the speed of products, open up new markets;
Reflections on the performance optimization of speed:
1. Do not try to put a good performance optimization;
2. Review the code;
3. The pressure measurement, recording the result;
4. find performance bottlenecks point, think of ways to optimize away;
5. Continue pressure, recording the result;
6. The discovery of the choke point, then optimization;
7. always concerned about the cpu, memory, network; (disk followed)
8. For some business scenarios, do spare downgrade strategy;
9. The pressure measurement, recording the result;
10. keep the performance monitoring;
11. The rollback scheme needs several;
12. optimization tools: jmx, jmeter, sonar, grafana,
Nagging: things did not look so simple.