------------------------------------------------------------------------------
It's a broad proposition, and if you don't think about it, it seems like something's a little bit more.
When from the perspective of the application, of course, the function of the more beautiful and better, but also to consider some future extensibility, the tedious duplication of work from the point of view of building a high-level abstraction package is better.
From a usability standpoint, there is a good one: a robust program with simple code.
In terms of performance, personal perception, a full understanding of the business can solve 80% of the problems, the computer hardware and procedures to solve the problem of 20%.
But generally speaking, there is no need to be drastic, in addition to changing the direction of business, the process is rarely big changes, the remaining 20% is the code to knock out, in the process of being interpreted they have vitality, many people are working for their performance, here are some of my understanding:
1. Easy-to-read procedures, with good process control, remember the single export principle.
2. Write simple procedures, direct to the target, the more concise the less vulnerable to loopholes.
3. Write efficient programs; Do not attempt to do anything to get the program to do, as much as possible to save overhead, that is, memory and CPU.
Before and after the paragraph to improve the code:
Before
After
Under discussion, what are the pros or cons of a simple change? Reply Analysis.
Proj:https://github.com/farwish/user-redis
Link:http://www.cnblogs.com/farwish/p/4675071.html
@ Black eyed poet <www.farwish.com>
What do we want to focus on when we write the program?