7 Stages of refactoring code

You've been trying to refactor a very old module, but it's disgusting if you just look at it. Documents, strange functions and names of classes, and so on, the whole module is like a ragged man with fetters, though able to walk, but it is already uncomfortable for people. In the face of this situation, the real programmers will not concede, they will accept the challenge of serious analysis, it is not afraid of rewriting. Eventually the module will be refactored, just as it did with the amazing programming that you've been introduced to. Here are a few stages of refactoring code,

First Stage – Despair

When you start looking at the modules you want to refactor, you'll feel as if it's simple, you need to change a class here, you need to change two to three functions, rewrite a few functions, it doesn't look like a big deal, and it's done in a day or two. So you're going to start refactoring, and then when you tweak refactoring some code, like changing some names, fixing some logic, and gradually, you'll find that this monster is so big, you'll see a code that doesn't even have an ambiguous comment, a completely confusing data structure, and some seemingly unwanted methods being tuned several times, You will also find it impossible to figure out the logic on a function call chain. You feel that this may not work for a week, and you are beginning to despair.

Phase II – find the simplest to do

You admit that the module you want to refactor is a scary monster, not one or two can be done, so you start to do something simple, such as renaming a few functions, removing some of the block of code, creating several constants to eliminate magic number, and so on, You know that doing this at least doesn't make the code worse.

Phase III – again desperate

But the next thing will get you to the wall again. You'll find that the flaws in the code are just a little bit of a problem, and correcting these things is completely useless, and all you have to do is rewrite everything. But you do not have the time to do so, and the code is not messy, coupled too much, let you despair again. So, you can only partially rewrite parts that don't take too much time, so that at least the old code can be reused more. It's not perfect, but you can try at least.

Fourth Stage – start to be optimistic

After you've tried to partially refactor the module a few days later, with the refactoring of several units, you find that the progress of the code is too slow, but at this point you know what the code should be changed to, and you've locked those modified classes after the pain. Yes, although your time budget is over-cost, although you have to do more, but you are full of hope, that it is worth it. The fire in your chest was lit again.

Fifth Stage – Quick Closure

At this time, you find that you have spent too much time, and the situation is becoming more and more complex, you feel that the situation you are facing more and more uncomfortable, you know you have been in a dilemma. You thought you'd just need a simple refactoring, but now you're dealing with rewriting everything. You start to realize that because you're a perfectionist, you want the code to be perfect. So you start to snub your documents and want to find a shortcut to rewrite the old code, and you begin to adopt some simple and rude, quick and a little dirty way. It's not perfect, but that's how you do it. Then, you start to run the test to do UT, find the UT report is all red, almost all failed, you panicked, so quickly fix the code, and then let UT be able to work. At this point, you pat your chest, said, no problem, so the code submitted.

Sixth stage – Modify a large number of Bug

Your rewrite is not perfect, although it has been tested, but those UT tests are a bit inappropriate for your new code, and although they didn't get an error, they were too small to cover all the situations and boundaries. So, after that, you'll need weeks or more to fix more and more bugs, which makes your design and code look ugly every time you quick-fix. At this point, the code is not as perfect as you expected, but you still feel that he is better than the beginning. This stage may take several months.

Seventh Stage – Enlightenment

After 6 months, you rewrite the module has a more serious bug. This makes the module you refactor more embarrassing. The problem you found was inconsistent with the original design, and you also found that the old code that you reconstructed was not as bad as it looked, and that old code did take into account some of the things you hadn't thought about. At this point, someone on your team came up and said that the module should be refactored or rewritten, but you didn't say a word, and hoped that the person who stood out could wake up in a few months.

——————

I do not know if this is your experience, I have experienced many times such a thing. For many maintenance projects, my mistakes made me a real conservative, I almost dared not move, it is afraid to see the code is very tastes. Of course, those agile consultants who have never written code will say that using TDD or UT can make your refactoring more effective and easier, because it makes them more valuable to me, but I want to tell you that it's irresponsible to say this out of the fact, which is like saying-- I ran into some trouble when I killed a pig, because I was not sure about the physiology of the pig, or it was a deformed pig, and the pig that I killed was hard to see, and the great agile consultant told me to use a faster and prettier knife . Software development is never so simple as killing a pig.

7 Stages of refactoring code