Refactoring-improving the design of existing code

Erich mentioned in the preface of refactoring:Code is read and modified much more times than it is written. The key to keeping code readable and easy to modify is refactoring.

What is the purpose of refactoring? The second chapter of the book has a special section for explanation. However, the first chapter presents a simple case to show a relatively complete reconstruction process. In this case, there are only three classes at first. One of the classes has about 50 rows of methods. At a glance, there are two words: uncomfortable. As mentioned in the bookIt does too many things..Even so, this program can still work normally ,...... The compiler does not care about the code, but when we plan to modify the system, it involves people who care about it. Poor systems are difficult to modify, because it is difficult to find a change point. If it is difficult to find a change point, programmers may make mistakes and introduce bugs..I think this is an important reason for restructuring.

If a method is too long, it means that many things are done and many steps are involved. In this way, once you need to modify the function, you must first read a long piece of code, then break down the function, find the code section involved in the modification, and so on, this will cause a lot of trouble for further development. In addition, the long decomposition method can help us find repeated code. I am afraid most programmers will understand the side effects of repeated code. Today, when I refactor the code developed in the last month, I first split dozens of methods into small code segments, I found that there are two classes and three methods that execute the same logic: Find a record based on a unique index of a table. This code can be completely split to reduce repeated code. If the database table structure changes in the future, we can modify only one of them. Otherwise, it is really too difficult to change it. If long code is not split, it is difficult to find repeated code from so many lengthy methods.

 

For the simple case in chapter 1, the reconstruction process is as follows:

 

We first split the long function,The first step is to find out the codeLogical clump and use extract method.

In addition, use a variable name that clearly expresses the meaning of the business logic.Good code should clearly express its own functions, and the variable name is the key to code clarity.SoIt is worthwhile to change the variable name.. I have encountered this code: A class provides an external public method. The main function of this method is to find some information in the database table and return it based on some input parameters. In the parameter list of this method, the parameter name uses the field name of the database table to be queried. The field naming rule for our database table isPK/FK+Abbreviated table name+Abbreviated actual field nameTo ensure that the field name cannot be too long, this process is "scaled down". If you are not familiar with database tables, it is difficult to determine the business meaning of the field name. Regardless of whether the field naming rules of the database table are correct, how can we use this method as the parameter name of the parameter list so that others can understand it?

In one case, we should doubt whether a method has put the wrong class:In most cases, the function should be placed in the object of the data it uses.(OrClass)If a method does not use any object information, but uses the information of another object, we should consider whether to move this method.

In the next step, replace temp with query is used to obtain a returned value, but no temporary variable changed is replaced with query. Martin says the reason for doing so is:They will cause a large number of parameters to be transmitted, but they are not necessary at all. You can easily lose their traces, especially in long functions.. However, in this case, I think it is bound to sacrifice performance. Martin also mentioned the performance problem. In Chapter 1, he talked about the issue of "refactoring and performance. But he believes that,You don't have to worry about performance during refactoring, but you need to worry about them only during optimization, but at that time you are already in a favorable position and have more options for effective optimization.. However, I may not have considered or encountered the issue of "refactoring and performance" in my actual work. Therefore, this issue needs further consideration.

In this simple case, a logic was originally to use a switch to calculate its cost based on the category of a rent (movie. Here, itBased on the attributes of another objectSwitchStatement is not a good idea. If you have to use it, you should also use it on the object's own data instead of on others' data..

Refactoring provides a more efficient and controlled code sorting technology.

The purpose of refactoring is to make the software easier to understand and modify. You can make a lot of changes within the software, but you must make very small changes to the software [observed external behavior. Or do not even cause changes. In contrast, [performance optimization]. Like refactoring, performance optimization usually does not change the behavior of components (except the execution speed), but only its internal structure. But the two have different starting points: Performance Optimization often makes the code hard to understand, but you have to do that to get the required performance.

When you use refactoring technology to develop software, you do not lose your time to two completely different actions: Add new features and refactoring. When adding new features, you should not modify existing code, just add new features. Refactoring means you can no longer add functions, just improve the program structure.You may do these two things alternately during software development, suchWhen adding new features, you can find that the program structure is changed, which makes it much easier to add features., So we refactored it, adjusted it, and continued to add new features. At any time, you should know exactly what you are doing.

Why Rebuild:

Improve Software Design

Make the software easier to understand

Help you find bugs

Wish you a better programming speed

 

Martin has a piece of text discussing the impact of repeated code on excellent design. I think it is very thorough:

Poorly designed Code usually requires more code, because the Code uses identical statements in different places to do the same thing. Therefore, an important direction of your current design is to eliminate repeated Code (Duplicate Code). Less Code does not make the system run faster, because it has almost no significant impact on the running track of the program. However, the decrease in the number of codes will make it much easier to modify programs in the future. The more code, the more difficult it is to modify correctly. Because more code needs to be understood. You have made some modifications here, but the system does not work as expected, because you have not modified another one-the Code author has almost the same thing, but the environment is slightly different. If repeated code is eliminated, you can make sure that the Code expresses all things and actions only once. This is the foundation of a good design.

The reconstruction at the beginning may only focus on the details. As the code becomes more concise, you will find that you can see some design aspects that you did not previously see. If I do not make these changes to the code, I may never see them, because I am not smart enough to imagine it in my mind.

 

When to refactor: refactoring should be performed anytime, anywhere. The reason why you refactor is because you want to do something else, and Refactoring can help you do those things well.

Three rules: Three Strikes and you refactor

Refactoring when adding features: Make the code to be modified easier to understand, and the code design cannot help me easily add the features I need

Rebuild when fixing errors: If you receive an error report, this is the signal to be restructured, because the code is clearly not clear-not clear enough to let you see bugs at a glance(But I think there is an error report, that is, the reconstruction signal is a bit too much)

Refactoring during code review: design review with a team, and code review with a reviewer. In extreme programming, paired programming forms bring the enthusiasm of code review to the extreme. Once this form is used, all formal development tasks are performed by two developers on the same machine. In this way, code reviews can be performed at any time during the development process, and refactoring is included in the development process.

 

What programs are difficult to modify:Difficult to read, with repeated logic, when adding a new line, it is necessary to modify the existing code, with complex conditional Logic

Therefore, we hope that the program:Easy to read, all logic is specified only in a unique location, new changes do not endanger existing behavior, as easy as possible to express conditional Logic

 

Indirection) And refactoring:

Value of the indirect layer:

Allow logical sharing: for example, a sub-function is called in two different locations, or a superclassA function inShare

Explain intent and implementation separately

Isolate changes:It is very likely that I use the same object in two different locations, one of which I want to change the object behavior. But if you modify it, I will take the risk of simultaneously affecting both. For this reason, I made a subclassAnd reference the subclass. Now, I can modify this subclassWithout having to bear the risk of inadvertently affecting another place

Encode the conditional logic:The object has an incredible mechanism-polymorphic messages), Flexible, flexible, and clear expression of conditional logic. As long as the display condition logic is converted to message) Form, which can reduce code duplication, increase clarity, and improve elasticity (Note: Send a message to an object, that is, call a function)

 

If the refactoring method changes the released interface, you must maintain both the new and old interfaces at the same time until all your users respond to the change at this time. In this case, let the old interface call the new interface. Do not copy the function implementation code. This will make it difficult for you to extricate yourself from repetitive code. You should also use JavaDeprecation.

JavaThere is also a special question about modifying interfaces. In throwsAdd an exception to the statement.

SignatureSo you cannot use delegationTo hide it. For this reason, I always likeDefine a superclassException (like java. SQLSQLException), And make sure that all publicThrowsClause.

 

Ask yourself at the design stage:How difficult is it to reconstruct a flexible solution with a simple solution? If the answer is[Relatively easy]Then you only need to implement the current simple solution.

 

When the system performance is poor: Even if you fully understand your program, please measure its performance. Do not speculate. Speculation will help you learn something, but you are wrong.

 

Refactoring and Performance: refactoring often slows down software operation, but it also makes software performance optimization easier. In addition to real-time systems with strict performance requirements, the secret of portable and fast software in any situation is: Write the tunable software first, and then adjust it to get enough speed.

Three methods for writing quick software:

Time pre-algorithm: generally used only for real-time systems with extremely high performance requirements. If you use this method, You Need To budget your design and allocate resources to each component in advance, including time and execution track. Each component cannot exceed your budget.

Sustained concern: this approach requires any programmer to try to maintain the high performance of the system at any time. This method is very common and attractive, but it usually does not play a major role. Once the performance improvement is distributed to every corner of the program, every improvement is only from a narrow perspective on program behavior. If you analyze most programs, you will find that it spends most of its time on half-code, 90%The optimization work is in vain, because the code you optimize is difficult to execute.

Use the above 90%Statistical data: when using this method, you build your own program in a good way of decomposition, without paying any attention to the performance until you enter the performance optimization stage-which is usually in the later stages of development. Once you enter this stage, you can adjust the program performance according to a specific program. In the performance optimization stage, you should first use a measurement tool to monitor the running of the program and let it tell you where the program consumes a lot of time and space. In this way, you can find out a small piece of code for the performance hotspot. Then you should focus on these performance hotspots and use the optimization methods in the aforementioned continuous concern method to optimize them.