Article introduction of Wulin.com (www.vevb.com): The word Refactoring was originally defined by Martin Fowler and Kent Beck. It is a modification that makes the internal structure of the software easier to understand and makes the software easier to change without changing the visible behavior of the software... It is a restrained way to organize code and minimize the chance of bug generation.
Sometimes, programmers come to me and say that they don’t like the design of something, and we need to give it a comprehensive reconstruction to correct the errors in it. oh oh. This doesn't sound like a good idea. And this doesn't sound like a refactoring...The word Refactoring was originally defined by Martin Fowler and Kent Beck. It is a modification that makes the internal structure of the software easier to understand and makes the software easier to change without changing the visible behavior of the software... It is a restrained way to organize code and minimize the chance of bug generation.
The result of the reconstruction is that shortcut methods are referenced, duplicate and dead code are removed, making the design and logic clearer. It is to use programming languages better and smarter. It is the advantage of using information you know now, but the developer at that time did not know - or did not use it. Continuously simplify the code to make them easier to understand. Continuously make their future changes easier and safer.
During this process, bugs were found and bugs were modified, which is not a reconstruction. Optimization is not a reconstruction. Strengthening exception capture and adding preventive code is not refactoring. Making the code easier to test is not a refactoring - although refactoring can achieve the same effect. All of these things are beneficial. But none of these are refactoring.
Programmers, especially those who do maintenance work, cleaning up code is one of their daily tasks. This is a basic job and must be done. The contribution of Martin Fowler et al. is to format the best practice methods of refactoring code and to archive the common and proven effective refactoring patterns - the goals of refactoring and the steps of refactoring - for archive classification.
Refactoring is simple. Writing tests before writing code as much as possible can prevent you from making mistakes. Small-scale, independent and secure structural adjustments to the code, and test them after each adjustment to ensure that you do not change the behavior characteristics of the code - the functions are the same as before, but the code looks different. Refactoring mode and modern IDE refactoring tools make refactoring easy, secure and inexpensive.
Don't refactor for the sake of refactoring
Refactoring can be regarded as a measure that can help your code changes. Code refactoring should be done before you make code changes, which will make it possible for you to be sure that you understand the code and make it easier and safer to introduce changes into the code. Perform a regression test on your refactoring action. Then make corrections or changes. Test again. Later, more code may be refactored to make your code change intention clearer. Complete test again. Reconstruct and change again. Or change, and then refactor.
You are not refactoring for the sake of refactoring, you are refactoring because you want to do other things, and refactoring can help you accomplish these things.
The scope of the refactoring should be determined by the code changes or code corrections you need to implement - what should you do to make the code changes safer and more concise? In other words: don't refactor for the sake of refactoring. Don't refactor the code that you don't intend to change or will not change.
Scratch Refactoring for understanding (Scratch Refactoring)
Michael Feather's book "Working Effectively with Legacy Code" mentions the concept of Scratch Refactoring; Martin Fowler calls it refactoring for understanding. This is used to deal with (or can't stand) code you don't understand, clean them up so that you can have a better understanding of what they do before you actually modify it, and it will also help you debug these codes. Once you can understand the true intention of a variable or method, rename them, give them a more appropriate name, delete the code you don't like to read (or find useless) , disassemble complex conditional statements, and break down long programs into several easy-to-understand mini programs.
Don't worry about reviewing or testing these changes. This is to make your reconstruction progress quickly - this allows these codes and how they run to produce a fast but incomplete prototype in your brain. Learn from it and throw them away. A brief reconstruction can also allow you to try various reconstruction methods and learn more reconstruction techniques. Michael Feathers suggests that you should pay attention to things that seem useless or particularly useful in the process, so that you can do things correctly after you complete this exercise and really modify them - make a little bit by bit when modifying, pay attention to the method, and modify and test.
What is large-scale reconstruction?
Simple but obvious reconstruction of the code: eliminate duplication, modify and change the variables and method names to make it more meaningful, refine the methods to make the code easier to understand and reuse, simplify the conditional logic, replace meaningless numbers with named variables, and bring together similar codes. Through these refactorings, you can get huge rewards in terms of code comprehensibility and maintainability.
Compared with these smaller, in-line reconstructions, more significant design reconstructions are significantly different from them - this is what Martin Fowler refers to as large reconstructions. Large, costly changes come with a lot of technical risks. This is not a cleanup code and design improvement in your programming process: it is a fundamental redesign.
Some people like to call redesign or rewrite or rebuild a system or rework a system called large-scale reconstruction. Because technically, these do not change the functional characteristics of the software - 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 reconstruction seems to be: one is to rewrite a piece of code, and the other is to rewrite a system. As long as you do it step by step, you can call it a reconstruction - whether you are trapped in replacing an old system with new code for years or large-scale transformation of the system architecture.
Large-scale refactoring will be awful. It may take weeks, months (or even years) to complete, and you need to make changes to many parts of the software. The software will not run as a result, and these changes need to be released in multiple times. You need to do temporary scaffolding and workarounds - especially when you use short-cycle agile development methods. At this time, a practical method like Branch by Abstract comes in handy, which can help you manage changes in your code over a long period of time.
And while developing new code, you also have to maintain the old code, which makes the code version control very troublesome and inconvenient to change, making the code very fragile and easy to make mistakes - this goes against the intended purpose of reconstruction. Sometimes this situation continues - this process of alternating new and old code can never be completed because the best benefit is done first, or because the consultant who initially brought the idea has done something else, or the budget has been reduced, and you hate maintaining such a procrastination project.
These are refactoring-those are not
It is wrong to incorporate the concept of reconstruction in such heavy-duty project development. They are fundamentally another kind of work with completely different development costs and risks. It confuses people's understanding of what reconstruction is and what reconstruction can do.
Refactoring can and should be integrated into your process of writing or maintaining your code - as an integral part of daily development/quality management, just like writing tests and code reviews. Refactoring should be completed quietly, continuously and understatedly. It requires us to divide our work energy into it, and it needs to take its existence into account in our construction period assessment and risk assessment. If done correctly, you don't need to explain or verify this part of the work to outsiders.
Taking a few minutes or an hour or two to refactor is like a modification in your development process and is part of the work. If it takes you days, or longer, it's not a refactoring; it's a rewrite, or a redesign. If you need to explicitly set aside a portion of the time (or the entire sprint cycle) to refactor the code, if you need to apply for approval to clean up the code, or use clean up the code as a development requirement, then you are not refactoring - even if you use the refactoring techniques and tools, you are still doing another kind of work.
Some programmers believe that it is their right and obligation to make fundamental and significant modifications to the code, and they will redesign and rewrite them in the name of refactoring, so that they will not let down their skills in the future. Redesigning and rewriting is sometimes the right thing to do. But out of frankness and clarity, please do not give these activities the name of reconstruction.