Definition of refactoring

Absrtact: Sometimes programmers come to me and say they don't like the design of something, and we need to give it a comprehensive refactoring to correct the bugs inside. Oh. That doesn't sound a good idea. And that doesn't sound refactoring refactoring.

Sometimes, programmers come to me and say they don't like the design of something, "We need to give it a complete refactoring" to correct the bugs inside. Oh. That doesn't sound a good idea. And it doesn't sound too refactoring ...

The word refactoring (Refactoring), originally defined by Martin Fowler and Kent Beck, is

A modification that makes the internal structure of the software easier to understand and makes the software easier to change without changing the way the software behaves visually ... It's a way of controlling the code and minimizing the probability of bugs.

The result of refactoring is to make design and logic clearer by referencing shortcut methods, by excluding repetitive code and dead code. It is better and smarter to use programming languages. It is in the advantage of using the information you now know, but the development programmers at the time did not know--or did not use it. Keep simplifying the code to make it easier to understand. Constantly making changes in the future easier and safer.

In the process of discovering bugs, modifying bugs, this is not refactoring. Optimization is not refactoring. Enhanced exception capture, increased preventative code is not refactoring. Making code easier to test is not refactoring--although refactoring achieves the same effect. All these things are good. But none of this is refactoring.

Programmers, especially those who do maintenance work, clean up code is one of their daily work. This is the basic work that must be done. The contribution of Martin Fowler and others is to format the best practices of refactoring code, and to archive and classify common, proven and effective refactoring patterns-refactoring goals and refactoring steps.

Refactoring is simple. Writing tests as much as possible before writing code can prevent you from making mistakes. Small, independent, and secure structural adjustments to your code, tested every time you adjust, to make sure you haven't changed the behavior of your code--the same functionality as before, except that the code looks different. Refactoring patterns and refactoring tools in the modern IDE make refactoring easy, secure, and inexpensive.

Don't refactor for refactoring

Refactoring can be used as a measure to help your code change. Code refactoring should be done before you make changes to your code to make sure you understand the code and make it easier and safer for you to bring the changes into the code. Perform regression tests on your refactoring actions. Then make corrections or changes. Test again. After that, you may need to refactor more code to make your code change intent clearer. Complete the test again. Refactor, then change. or change, and then refactor.

You are not refactoring to refactor, you refactor 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 revisions that you need to implement-what should you do to make the code change more secure and concise? In other words: do not refactor for refactoring. Do not refactor code that you do not intend to make or change.

Simple refactoring for Understanding (Scratch Refactoring)

Michael Feather's "sharable effectively with Legacy code" refers to the concept of abbreviated refactoring (Scratch Refactoring); Martin Fowler called it "refactoring for understanding." This is used to deal with the code that you don't understand (or intolerable) and to clean it up so that you have a better understanding of what they are doing before you can actually modify it, and it also helps you debug the code. Once you have a clear idea of the true intent of a variable or method, rename them, give them a more appropriate name, delete the code you don't like (or feel useless), disassemble the complex conditional statement, and break the long program into several small, easy-to-understand programs.

Don't be bothered to review or test these changes. This is to allow your refactoring to advance quickly--this allows the code and its operating principles to produce a fast but incomplete prototype in your brain. Learn from them and throw them away. Simple refactoring also allows you to try different ways to refactor and learn more refactoring techniques. Michael feathers suggests that you pay attention to things that look useless or useful in the process, so that when you're done doing this, you really need to change them to do the right thing--1.1 points to change, a way to modify the test.

What is "massive" refactoring?

Simple but obvious refactoring of code: Eliminate duplication, modify variables and method names to make them more meaningful, refine your code to make it easier to understand, easier to reuse, simplify conditional logic, replace meaningless numbers with named variables, and bring similar code together. With these refactoring, you can get a huge return on the understanding and maintainability of the code.

In contrast to these smaller, inline refactorings, there are significant differences in design refactoring-this is what Martin Fowler refers to as "large refactoring". Large, costly changes, accompanied by a large number of technical risks. This is not the cleanup code and design improvements in your programming process: this is a fundamental redesign.

Some people like to redesign or rewrite a system or rebuild a platform or rework it called "Mass refactoring." Because technically, these do not change the functional characteristics of the software-business logic, software input and output are still the same as before, "just" design and code implementation has changed. The difference between it and conventional refactoring seems to be that one is rewriting a piece of code, one is to rewrite a system, as long as you do it step-by-step, you can call it "refactoring"--whether you're stuck with an old system for new code, or a massive transformation of the system architecture.

"Massive refactoring" will be bad. 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, and it needs to be released several times, requiring you to do a temporary scaffolding and workaround-especially if you are using a short cycle of agile development methods. This is the practice of branch by abstraction, which helps you manage changes in your code over a long period of time.

And while you're developing new code, you have to maintain the old code, which makes code versioning cumbersome, inconvenient to change, making the code vulnerable and prone to error--and this is going against the intended purpose of refactoring. Sometimes this will continue--the process of alternating old and new code can never be completed, because the most profitable part is done first, or because the consultant who originally brought the idea has done something else, or the budget has been cut off, and you hate to maintain such a dilatory project.

These are refactoring--those aren't

It is not right to mix the refactoring concept in this heavy project development process. They are fundamentally another kind of work, with completely different development costs and risks. It confuses people's understanding of what refactoring and refactoring can do.

Refactoring can and should be incorporated into the process of writing code or maintaining code-as part of daily development/quality management, like writing tests and code reviews. Refactoring should be done quietly, consistently and quietly. It requires us to give it a part of the effort, and it needs to be taken into account in our duration assessment and risk assessment. If you do it right, you don't need to explain or verify this part of the work to outsiders.

It takes a few minutes, one or two hours to refactor, like a modification in your development process and a part of your job. If it takes you a few days, or longer, it's not refactoring; it's rewriting, or redesigning. 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 your code, or to clean up your code as a development requirement, you're not refactoring-even if you're using refactoring techniques and tools, you're still doing another job.

Some programmers think that fundamental and significant changes to the code are their rights and obligations to redesign, rewrite in the name of refactoring, and to live up to their skills in the future. Redesign and rewrite sometimes is the right thing to do. But for the sake of frankness and clarity, do not assign these activities to the name of refactoring.