Refactoring to improve the design of existing code (Reading Notes 1)

// Copying and pasting pose a huge maintenance challenge to the program. The same piece of code should never appear in different places. Of course, you can do this, but once a problem occurs with this code, do you remember to modify it?

 

// If you find that you need to add a feature for the program, and the code structure makes it difficult for you to achieve your goal, you should first refactor the program to make it easier to add features, then add the feature. Never say that you have time to rebuild. If you have time to redo it, you will never do it. (You can analyze it yourself. First, you need to recode all the time given by the company, once the code has been completed, it is called "time available"}. It is estimated that it is time for acceptance. Do you dare to change anything at this time ?).

 

// Before refactoring, first check whether you have a set of reliable testing mechanisms. These tests must have self-check capabilities to prevent regression testing.

 

// Refactoring must be performed in tiny steps, which is conducive to discovering introduced bugs.

 

// Any dummies can write code that computers can understand. They can only write code that humans understand.

 

// Sometimes, the project's initial understanding of the responsibility of an object is unclear. In other words, the method is written in a place where it should not be written. At this time, there is a rule that can help us: the method should be placed in the object of the data it uses.

 

// Using a query instead of a temporary variable will definitely reduce the performance to a certain extent. However, if this reduction is acceptable, the benefit of reducing temporary variables is shown (I think it is prudent to use it ).

 

// I will not remember anything that can be queried immediately, because I am afraid it will fill my brain.

 

// I am not a great programmer, but a programmer with good habits.

 

// You should not take special time for refactoring. refactoring is just to better add new things later. refactoring should be performed anytime, anywhere.

 

// A good principle: When I do something for the first time, I just do it. The second time I did something similar, I would dislike it, but I still can do it. For the third time, it is directly restructured.

 

// Three points for refactoring: refactoring when adding features, refactoring when fixing bugs, and code review.

 

// The earlier the reconstruction is performed, the better. reconstruction should not be performed at the end of the project.

 

// When a system-level problem occurs, such as high CPU consumption and high memory usage, do not indulge in the problem. Instead, use a tool to locate the problem and solve the problem.

 

 

 

// Small reconstruction knowledge points:
// 1. refactor a piece of code and select a method. If the local variables in the Code are not modified in the refactoring code, you can pass in the method through parameters.
// 2. When you refactor a method, the modification may cause the caller to modify it. In this case, a new method is provided to make the old method call the new method a feasible solution.