Transformation in code refactoring

In the past few days, I have to sort out the code I wrote half a year ago. When I read the code, I found that there were a lot of places that were not well written, commonly known as "bad taste, refactoring, required.

 

A few years ago, I read the book refactoring to improve the design of existing code. Although I have limited memory for various refactoring modes or methods, I still remember the essence: Changing the code without changing the external performance of the software, step by step.

 

In fact, refactoring is the basic work of a developer and is used in every development process. Without refactoring and testing, it is difficult to ensure the code quality. Some people will say that refactoring is not used. In fact, the simplest example is that when you find that several parts of a class use the same code, you extract these lines of code to a private function for reuse. This is a reconstruction. So, don't show off people that you will refactor. This is a basic skill.

 

I haven't updated my blog for a long time. Let's talk about some of my experiences.

 

1. clear purpose. Code is a product of balance. In many places, a balance is maintained, with a balance between functions and performance, and a balance between reliability and maintainability, there must be a goal to improve the local code or improve the class structure. Different methods can be implemented only for different purposes.

 

2. Evaluate the impact. It is recommended that you have an estimate before the change to avoid unnecessary consequences. In the "bad taste" code, it is very likely that the whole body is triggered, pay attention to security. If only changes are made to the private members of the class, the impact is usually limited. if changes are made to the public or protected members, pay attention to them, A simple evaluation method is to make full use of IDE's search, reference, and other functions to find out all the lines of code that have referenced this member and see how wide the impact scope is, if some code is not under your control, consider this refactoring with caution.

 

3. Change the structure with caution. When defining the class structure, the designer or architect must have his or her comprehensive consideration. Please be careful before you fully understand it. Do not use the design pattern to present the existing structure. The design pattern is a guide. If the design pattern is still hard to be applied after learning, it would be better to skip this rigid thinking. Therefore, if you want to make such a restructuring, please work with your designers, architects, or experienced colleagues unless you are a designer yourself.

 

4. small steps forward. Every change should be as small as possible, so that the impact can be limited to a small scope. Like a formula, if you change several of the variables at the same time, it is hard to say which one affects the result, but if you change only one of them at a time, you can confirm the impact on the results. Especially when the Code has completed the user's needs, the reconstruction is only to make the Code better, do not affect the external performance that has been confirmed by the user.

 

5. Test. Whether your development is test-driven or not, testing during refactoring is a necessary means to ensure the code is correct. Modify-compile-test, repeat this process until the goal is achieved.

 

When you spend a few minutes or weeks refreshing the code, you can look back and compare it with the previous "Bad taste". I think you will like the code, refactoring occurs when you write a line of code and becomes the encoding capability.

If you have a few lines of code, there will be less errors. Don't feel bad about the code you deleted. Although it is your painstaking efforts, it is already history and the transformation has been completed in refactoring code.

 

 

-- Welcome to reprint, please indicate the source of http://blog.csdn.net/caowenbin --