Refactoring Code 7 Phases-Refactoring

You've been thinking about refactoring a very old module, but you just look at it and you get sick. Documents, strange functions and names of classes, and so on, the whole module was like a ragged man with fetters, though he could walk, but it was already uncomfortable. In the face of this situation, the real programmers will not give up, they will accept the challenge of serious analysis, that is afraid to rewrite also at the expense. Eventually that module will be reconstructed by them, just as the slaughter-like programming in the ecstasy-programmed way we've been introduced before. Here are a few stages of refactoring the code from: The 7 stages of refactoring, the following translation is just a paraphrase.

First Stage – Desperation

When you start to look at the modules you want to refactor, you'll feel like it's easy to change a class where you need to change two or three functions, rewrite a few functions, it doesn't look like a big deal, it's a day or two. So you start refactoring, and then when you tweak the refactoring code, for example, to change some of the naming, repair some logic, gradually, you will find that the monster was so big, you will see the code is not even ambiguous comments, completely confused data structure, and some seemingly do not need to be tuned several times, You'll also find it impossible to figure out the logic on a function call chain. You feel that this may be a week of uncertainty and you are beginning to despair.

Second Stage – Find the easiest to do

You admit that the module you're trying to refactor is a scary monster, not one or two, so you start doing simple things like renaming a few functions, removing some code impediments, generating several constants to eliminate magic number, and so on, You know that doing this at least doesn't make the code worse.

Phase III – Despair again

But the next thing is going to put you on the wall again. You will find that the flaws in the code are perfunctory, and correcting them is completely unhelpful, and what you should do is rewrite everything. But you do not have the time to do so, and these code cut not disorderly, coupled too much, let you once again despair. So, you can only partially rewrite parts that don't take much time, so that at least that old code can be reused more. It's not perfect, but at least you can try.

Phase IV – Optimism begins

After you've tried to partially refactor the module a few days later, as you reconstructed several units, although you found that the progress of improving the code is too slow, at this point, you already know the code should be changed to what, you in pain after also locked those modified class. Yes, although your time budget has been overrun, although there are more things to do, but you are full of hope that it is worthwhile. The fire in your chest has been lighted again.

Phase Fifth – Rapid closure

At this time, you find that you have spent too much time, and the situation is getting more complicated, and you feel that the situation you are facing is getting more and more unsettling, and you know you are in trouble. You thought you needed a simple refactoring, but now you're dealing with rewriting everything. You start to realize that the reason is because you are a perfectionist and you want to make the code perfect. So you start to snub your documentation and want to find a shortcut to rewrite the old code, and you start using some simple, rough, quick, and dirty methods. It's not perfect, but that's how you do it. Then, you start to run the test to do UT, found that the UT report is all red, almost all failed, you panic, so quickly fix the code, and then let UT can work. At this point, you pat yourself on the chest, said, no problem, so the code submitted.

Phase Sixth – Modify a large number of bugs

Your rewrite is not perfect, although it passed the test, but those UT test for your new code is a bit inappropriate, although they have no error, but they test the scope is too small, did not cover all the situation and boundaries. So, after that, you'll need weeks or more to fix more and more bugs, which makes your design and code look uglier after every quick-fix. At this point, the code is not as perfect as you would like it to be, but you still think he's better off than he started. This stage may be a few months.

Phase Seventh – Awareness

After 6 months, you rewrite the module again a more serious bug. This makes the module you refactor become even more embarrassing. The problem you found was inconsistent with the original design, and you found that the old code you reconstructed was not as bad as it initially seemed, and that the old Code did take into account something you hadn't thought about. At this point, someone in your team came out and said that the module should be refactored or rewritten, and you were silent and hoping that the person who stood up would be enlightened in a few months.

——————

I do not know if this is your experience, I have experienced many times such a thing. For a lot of maintenance-type projects, the mistakes I made made me a real conservative, I hardly dared to move, I was afraid to see the code very taste. Of course, agile consultants who have never written code must say that using TDD or UT can make your refactoring more efficient and easier, because it makes them more valuable to me, but I want to tell you that this kind of argument is irresponsible, like saying--I was having some trouble killing pigs, Because I do not know the biological structure of the pig, or this is a malformed pig, the pig I killed is very difficult to see, and the great agile consultant told me to use a faster and more beautiful knife. Software development is never that simple, killing pigs is the same.

From:https://coolshell.cn/articles/5201.html