Reconstruction of the seven-stage code

& http: //www.aliyun.com/zixun/aggregation/37954.html "> You've been thinking about refactoring a very old module, but you're just nibbling at it. Weird functions and classes Naming, documenting, etc. The entire module is like a poor ragged man with a toe, but it feels uncomfortable to walk in. In the face of this situation, as a true programmer, he will never admit defeat , They will take the challenge, analyze it carefully, and even rewrite it, and eventually the module will be refactored by them, just as slaughtered programming was done in the old-fashioned programming we used to introduce.

Here are a few phases of refactoring code:

The first stage - despair

When you begin to look at the module you want to refactor, you may find it as simple as changing a class here, changing two or three functions there, rewriting several functions, and it looks like no big deal, A day or two can get it. So you get started refactoring, and then when you restructure and rebuild some code, such as fixing some logic, changing some naming, gradually, you will find that this monster was so large, you will see inconsistent with the code or even vague Unclear annotations, completely messed-up data structures, and some seemingly unwanted methods that have been tweaked several times, and you also find it impossible to understand the logic behind a function call chain. At this moment you may feel that this matter may be up for a week, and you begin to despair.

The second phase - to find the easiest to do

You acknowledge that the module you are trying to refactor is a scary monster that can not be done in a second or two, so you start to do something simple, such as removing some code obstruction, renaming a few functions, generating A few constants to eliminate the magic number and so on, you know at least this will not make the code worse.

The third stage - despair again

But the next thing will make you hit the wall again. You will find those flaws in the code is something insurmountable, correct these things do not help, you should do is rewrite everything. But you do not have time to do this, and the code is not chaos chaos, coupling too much, so you once again despair. So, you can only partially rewrite parts that do not take too much time, at least for the old code to be more reused. Although not perfect, but at least you can try.

The fourth stage - start optimism

A few days after you've tried to partially refactor the module, and after refactoring a few cells, you've found that improving the code is slow, but at this point you already know what code should be changed to, You also lock those modified classes after suffering. Yes, although your time budget is over-spending, you have plenty to hope for, and think it is worth it. The fire in your chest was lit again.

The fifth stage - quickly settled

At this time, you find that you have spent too much time, and the situation becomes more complicated. You feel that the situation you are facing is getting more and more disturbing. You understand that you have already got into trouble. You had thought that you needed only a simple refactoring, but now all you have to face is rewriting everything. You begin to realize that the reason is because you are a perfectionist and you want to make the code perfect. So you start to neglect your document and want to find a shortcut to rewrite the old code, you start with some simple and rude, fast and a bit dirty way. It's not perfect, but you do it. Then you start running the UT test and find that the UT report is all red, almost all failing, and you panic so quickly fix the code and let UT work. At this point, you patted your chest, said that no problem, so put the code submitted.

The sixth phase - modify a large number of bugs

Your rewriting is not perfect. Although it has been tested, those UT tests are a little less appropriate for your new code, and although they are not complaining, they are too small to test and do not cover all situations And the border. So after that, you'll have to fix more and more bugs in a matter of weeks or longer, making your design and code harder and harder to see after every quick-fix. At this point, the code is not as perfect as you expected, but you still think he is better than the beginning. This stage may take months.

The seventh phase - enlightenment

After six months, you rewritten the module out of a more serious bug. This makes your refactoring that module more embarrassed. The problem you found was inconsistent with the original design. You also noticed that the old code that you reconstructed was not as bad as it used to be. That old code did take into account something you did not consider thing. At this moment, someone in your group stands up to say that the module should be refactored or rewritten, and you are quietly silent, and hopefully the one who comes out will be able to awake in a few months.

------

Do not know if this is your experience, I have experienced many times such a thing. For many maintenance projects, the mistakes I made made me a real conservative, and I almost did not dare to move, even though I could see the code was out of place. Of course, agile consultants who have never written code will definitely say that using TDD or UT can make your refactoring more efficient and easier because it makes them seem more valuable to me, but I want to tell you that this This is like saying - I ran into some troubles while killing a pig because I did not know the physical structure of the pig, or it was a deformed pig, which led me to kill The pig is hard to see, and the great agile consultant tells me to use a faster and more beautiful knife. Software development is never that easy, killing pigs too.