[Reprint] 7 phases of refactoring code

you tried to refactor a very old module, but you just looked at it and it was so disgusting. The document, the naming of strange functions and classes, etc. The whole module is like a tattered person with his feet. Although he can walk, he is already quite uncomfortable. In the face of this situation, the real Program personnel will not admit defeat, and they will accept the challenges for careful analysis, so they are afraid of rewriting. In the end, that module will be restructured by them, just like the slaughter-type programming in the thrilling programming methods that we 've introduced before. The following are several phases of Code reconstruction. the article comes from: the 7 stages of refactoring. The translation below is only a free translation.

Phase 1-despair

before you start to view the modulo You Want To refactor Block, you will think it is very simple, here you need to change a class, there need to change two to three functions, rewrite a few functions, it seems no big deal, it will be done in a day or two. So you start to refactor, and then when you adjust and refactor some code, such as modifying some names and repairing some logic, gradually you will find that this monster is so big, you will see comments that are not consistent with the Code or even vague, completely confused data structures, and some seemingly unnecessary methods have been tuned several times, you will also find that you cannot find out the logic of a function call chain. You may feel this thing is wrong for a week, and you are desperate.

Stage 2-find the simplest solution

You admit that the module You Want To refactor is a terrible monster. It can be done in a minute or two, so you start to do some simple things, such as renaming several functions, remove some code obstacles and generate several constants to eliminate magic number. You know that doing so will at least not make the code worse.

Stage 3-despair again

But the next thing will let you hit the wall again. You will find that the flaws in the Code are not painful, and correcting these things is completely useless. What you should do is to rewrite everything. But you don't have time to do this, and the code is too messy and coupled, making you desperate again. Therefore, you can only partially rewrite those parts that do not take too much time, so that at least these old codes can be reused more. Although not perfect, you can at least try it.

Stage 4-start optimism

A few days after you try to partially refactor this module, after refactoring several units, although you find that the progress of code improvement is too slow, you already know what code should be changed, and you have locked the modified classes after suffering. Yes, even though your budget has been overspent and you have to do a lot of work, you are still hopeful and think it is worthwhile. The fire in your chest was ignited again.

Stage 5-quick conclusion

at this time, you find that you have spent too much time, and the situation is getting more and more complex, you feel The more you face, the more uneasy you are. You understand that you are in trouble. You thought you only needed a simple refactoring, but now you have to rewrite everything. You begin to realize that the reason is that you are a perfectionist and you want to make the code perfect. So you began to neglect your documents and wanted to find a shortcut to rewrite the old code. You began to adopt some simple, rough, fast, and dirty methods. It's not perfect, but you did it. Then, you started to run the test for UT and found that the UT reports were all red and almost all failed. You panicked, So you quickly fixed the code and then made ut work. At this point, you pat your chest and said, "No problem, so you submitted the code.

Stage 6-modify a large number of bugs

Your rewrite is not perfect. Although it has passed the test, those ut tests are not suitable for your new code. Although they have not reported any errors, their testing scope is too small, all situations and boundaries are not covered. Therefore, it will take several weeks or longer for you to fix more and more bugs, this makes your design and Code become increasingly ugly after every quick-fix. At this time, the Code is not as perfect as you expected, but you still think it is better than the beginning. This phase may take several months.

Stage 7-awareness

After six months, another serious bug occurred in the module you wrote. This makes the module you restructured more embarrassing. The problem you found was inconsistent with the original design. You also found that the old code you reconstructed was not as bad as it was originally, the old code did consider things you did not consider. At this time, someone in your team said that this module should be restructured or rewritten, but you did not say anything, I hope that the person who stood up will be enlightened in a few months.

I don't know if this is your experience. I have experienced this many times. For a lot of maintenance projects, the mistakes I made me a real conservative, and I almost did not dare to move, so I was afraid that the code would not taste the same. Of course, agile consultants who have never written code will say that using TDD or UT can make your refactoring more effective and easier, because it will make them more valuable, however, I want to tell you that this is irresponsible because it is just like -- I encountered some trouble when I killed a pig, because I was not clear about the physiological structure of the pig, or this was originally a malformed pig, which made the pig very ugly, the great agile consultant told me to use a faster and more beautiful knife . Software development is never that simple, as is pig.