Refactoring --- Who are you ?!

I have just read Xiaolu's understanding of system restructuring, and I am excited to talk about my one-sided understanding of restructuring.

Tip

Don't think of refactoring when you need new features or bugs in the original program.

When Will reconstruction start? This is the first question to consider. Is refactoring started when a function is not completed? No. Are all functions ready for reconstruction? Not to mention. Refactoring is a task that runs through program development. When a function is completed (can work normally, through unit testing), reconstruction should begin. Since all of them have passed the test, should we rebuild them? You're fine? Well, it's because it's "nothing to find." Once the project is busy, or when programmers are lax in their work, refactoring will be thrown to one side. (I personally experienced this) the direct consequence is that the program quality is getting worse and worse, and you do not want to continue its development.

Now you may ask, "since all tests have passed, what else can be reconstructed ?" Right? What should we reconstruct? Bad Smell! Have you read the rebuild book? What does it write? What is the value of this book? This article introduces how to reconstruct the technology? Tell you why rebuild? Error! The value of this book is that it lists the Bad Smell that should be restructured one by one, and gives the opinions on how to reconstruct and solve these Bad Smell problems, otherwise, you can read the book once! The thought of reconstruction is very easy to understand. To use it well, we need to rely on experience. Martin Fowler gave us those experiences. OK. Do you think the list is too long? I will give you a Bad Smell --- repeat. When are there no duplicates in your code? Basically, you can skip restructuring. It is better if your code has good readability.

Tip

The most important and common Bad Smell-repetition

Refactoring is not a dispensable thing. A good programmer should always put the idea of refactoring in his mind. Only by constantly Refactoring can you develop a qualified Program. Of course, if you call a program that is qualified by some people in some cases, you can turn off your IE. When an interface is created, a pattern application may come from your refactoring. What is the pattern in your mind? The pattern that emerged in your code through refactoring is the best embodiment.

Refactoring is not a small modification. Every small step in the refactoring process is only a small modification. When you complete a refactoring, you will find that your code has changed its structure completely in addition to its functionality, the original class is gone, the new interface is coming out, and many new classes are added. The original method is moved to the new class, as if there was a cosmetic operation. Not broken! If every reconstruction you perform is a small repair or makeup task, either your pre-judgment capability is too strong or your re-construction is not performed. Don't laugh! Most people laugh at the latter. Compatibility? Dude, isn't your system ready yet? Are you talking to me about compatibility?

Tip

Don't be afraid that your refactoring will make your code invisible. What should I do for unit testing?

Have you heard of TDD? Do you know what TDD is? What is the most important thing in TDD? Test? Error! The most important thing about TDD is refactoring. The essence of TDD is constant reconstruction. Testing is used to ensure the security of refactoring and serves the refactoring.
Do you know what object orientation is? Interface! Do you know what TDD is? Rebuild!


I think it's too theoretical? Here are some of my experiences:
1. refactoring has become an indispensable part of my development.
2. During a development period in the past, because the customer did not put too much time pressure on me in the early stage, I had a high reconstruction frequency and the design became increasingly satisfactory to me. At the end of the project, I set every day how many functions must be completed, which greatly compromises my refactoring. In addition, due to the long-term investment in a project, it also makes me tired of refactoring. Because the quality of the project is not very direct to me. I will do better without too much pressure and more encouragement and support for my "perfect" performance.
3. Because the project involves the UI (almost no project does not involve the UI), I have no sense of security in the refactoring process. This is also a major factor that seriously restricts refactoring. A better testing team or a better UI automation testing framework will also allow me to refactor more boldly.

Related Articles:

Evolution of a drawing program
Test-Driven Development --- Rss Reader Item Marker

A little nonsense:
Speaking of Refactory. Haha, A Prefactoring has emerged recently, but this title is estimated to cater to the market and there is nothing new. But the writing is not bad. I 'd like to see how to develop a program from scratch. However, I guess it won't win the book on SOA mentioned in the nomination of Jolt. Jolt, which is good. I 'd like to know more about SOA and strongly recommend it.