What refactoring is, and what it isn' t

Refactoring)The term was initially defined by Martin Fowler and Kent Beck. It is a change that makes the internal structure of the software easier to understand, making the software easier to change without changing the visible behavior of the software... It is a controlled way to sort out code and minimize the chance of bugs.

The reconstruction results refer to the shortcut method, removing duplicate code and dead code, so that the design and logic are clearer. It is better and smarter to use programming languages. The advantage is the information you know now, but the development programmers at that time do not know -- or are not used. Constantly simplify the Code to make it easier to understand. Constantly making future changes easier and safer.

In this process, bugs are found and bugs are modified. This is not a refactoring. Optimization is not refactoring. Enhancing exception capture and Adding preventive code is not refactoring. Making code easier to test is not refactoring-although Refactoring can achieve the same effect. All these things are beneficial. But none of these are refactoring.

Programmers, especially those who do maintenance work, clean up code is one of their daily work. This is a basic task and must be done. Martin Fowler and others contributed to formatting the best practices for refactoring code, and archiving and classifying common and proven reconstruction modes-reconstruction objectives and reconstruction steps.

Refactoring is simple. Try to write the test before writing the code to prevent mistakes. Small-scale, independent, and secure code structure adjustment. After each adjustment, you must test the Code to ensure that you have not changed the behavior characteristics of the code-functions are the same as before, but the code looks different. Reconstruction modes and modern reconstruction tools in IDE make refactoring easy, secure, and cost-effective.

Do not refactor for reconstruction

Refactoring can be considered as a way to help you with code changes. Code refactoring should be performed before you change the code, so that you can be confident that you understand the code, making it easier and safer to introduce the change into the code. Perform regression tests on your refactoring actions. Then make corrections or changes. Test again. Later, you may need to refactor more code to make your code change intent clearer. Perform another comprehensive test. Rebuild and change. Or change, and then refactor.You are not Refactoring for reconstruction, because you want to do other things, And Refactoring can help you complete these things.

The scope of refactoring should be determined by the Code changes or code corrections you need to implement-what should you do to make code changes safer and more concise? In other words: Do not refactor for reconstruction. Do not refactor the code that you do not intend to change or will not change.

Scratch Refactoring)

Michael Feather's "Working processing tively with Legacy Code" book mentions the concept of Scratch Refactoring. Martin Fowler calls it "Refactoring for understanding ". This is used to deal with the (or intolerable) code that you don't understand and clean it up so that before you actually want to modify it, you can have a better understanding of what they do, and it also helps you debug these codes. Once you understand the true intent of a variable or method, rename them, give them a more appropriate name, and delete code that you don't like (or feel useless, disassemble complex conditional statements and break down long programs into several small programs that are easy to understand.

Do not review or test these changes. This is to make your refactoring fast-this allows the Code and their running principles to generate a fast but incomplete prototype in your brain. Learn from them and then discard them. Simple refactoring also allows you to try different refactoring methods and learn more refactoring techniques. Michael Feathers recommends that you pay attention to things that seem useless or especially useful during this process so that when you finish this exercise and actually modify them, only in this way can we make things right-when we modify the things, we should focus on methods and test while modifying.

What is "large-scale" reconstruction?

Simple but obvious refactoring of the Code: Eliminate duplicates, modify variables and method names to make them more meaningful, refine methods to make the code easier to understand and reuse, and simplify the conditional logic, replace meaningless numbers with named variables and combine similar code. Through these refactoring, you can get a huge return on the comprehensibility and maintainability of the Code.

Compared with the small and intra-row refactoring, the more significant design refactoring is significantly different from the one mentioned by Martin Fowler ". Large and costly changes come with a large number of technical risks. This is not a clean-up code and design improvement in your programming process: this is a fundamental re-design.

Some people like to redesign or rewrite a system or rebuild a platform or call it "large-scale refactoring ". Technically speaking, these do not change the features of software functionality-business logic, software input and output are still the same as before, but the design and code implementation have changed. The difference between it and conventional refactoring seems to be: one is to overwrite a piece of code, the other is to overwrite a system, as long as you do it step by step, you can call it "refactoring"-whether you have been stuck replacing an old system with new code for years or performing large-scale system architecture transformation.

"Large-scale reconstruction" will become very bad. It may take weeks, months (or even years) for you to complete, and you need to modify many parts of the software. Therefore, the software cannot run and you need to release these changes multiple times. You need to make a temporary stand (scaffolding) and workarounds-especially when you adopt a short-cycle agile development method. Branch
By using action can be used to manage changes in code over a long period of time.

In addition, you need to maintain the old Code while developing new code, which makes code version control very troublesome and inconvenient to change, making the code very fragile, easy to make mistakes-this is contrary to the intended purpose of restructuring. Sometimes this situation will continue-this process of switching between the old and new code can never be completed, because the most beneficial part is the first to complete, or because the consultant who initially brought this idea has already done something else, or the budget has been reduced, and you also hate maintaining such a drag-and-drop project.

These are refactoring-those are not

It is wrong to mix the concept of refactoring into this heavy-duty project development process. They are fundamentally another kind of work, with completely different development costs and risks. It obfuscated people's understanding of what refactoring is and what restructuring can do.

Refactoring can and should be integrated into the process of writing or maintaining Code-as part of daily development/Quality Management, just like writing tests and code reviews. Reconstruction should be completed in a quiet, continuous, and low-key manner. It requires us to allocate part of our work energy to it, and it needs to take into account its existence in our period assessment and risk assessment. If you do it right, you do not need to explain it or verify it with outsiders.

Taking a few minutes or an hour or two for refactoring is like a change in your development process and is part of your work. If it takes you several days or longer, it is not refactoring; it is rewriting or re-design. If you need to explicitly set aside some time (or throughout the sprint cycle) to refactor the code, if you need to apply for approval to clean up the code, or clear the code as a development requirement, then you are not refactoring-even if you use the refactoring technology and tools, you are still doing another job.

Some Programmers think that the fundamental and major changes to the Code are their rights and obligations. They re-design and rewrite the code in the name of restructuring. For the future, they will not be able to live up to their skills. Redesign and rewriting are sometimes the right thing to do. However, out of frankness and clarity, do not assign these activities in the name of refactoring.