Reconstruction and serialization of big talk 6: a true lie

After some previous explanations, I believe you have a preliminary understanding of system restructuring. Everything seems to tell us that system restructuring is always irrelevant to demand changes. But at this time, I have to tell you that this is a real lie.

Our software system is always in a change, and is often a process from simple to deep, from easy to difficult. However, when the complexity of the system changes, we should promptly adjust our design to adapt to new changes. However, we did not do this, so our system maintenance becomes increasingly difficult. To solve our problem, we must optimize our program through System Reconstruction to adapt it to business needs. There is no doubt that demand changes are the main driver for us to restructure.

However, system refactoring requires that we cannot change the external behavior of the software, which means that we cannot add any new features to the software during the refactoring process. refactoring seems to be unrelated to the change. This is a bit confusing. We tried restructuring because of changes, but restructuring won't let us change it! The key to cracking this true lie is that system restructuring does not prohibit us from making changes, but should be done in the form of "two hats.

What is "two hats? That is, when we need to change the system, we should divide the change process into two steps: first, rebuild our system without adding any features to meet new requirements, and then start to change, to meet new requirements. The first step is exactly what we call refactoring. It must ensure that the original functions are correct, and make the system structure adapt to new requirements. To achieve this goal, we need to make refactoring without changing the external behavior of the software. All we need to do is to adjust its internal structure, and the external functions remain unchanged. When the internal structure of the software can adapt to new requirements, we start to add new features to meet new requirements.

You may ask, why is it so complicated? Let's first analyze how we used to add new features. When a user comes to a new requirement, the primary principle of code modification is that changes to the new requirement cannot affect previous functions. How did we achieve this in the past? In fact, there is no good way. An intuitive idea is that the less the original code is changed, the smaller the number of changes, the minimum risk of modification errors. Because of this, even if the original program does not meet new requirements, the programmer does not want to modify the structure of the program, but adds the program to the existing code continuously. With the passage of time, more and more programs are added, and the system maintenance costs are getting higher and higher.

This is not the concept of system refactoring. Here, when the original program does not meet new requirements, the strategy we adopt is a "poor design with zero tolerance" strategy, that is, restructuring the system first to adapt to new requirements, then, we can easily fulfill these requirements. Because "without changing the external behavior of Software", we can easily establish a testing mechanism to ensure the reconstruction success with quality under the continuous supervision of the testing mechanism. Then, when we implement new features, we can ensure that they are easy to implement and ensure readability, maintainability, and changability. This process avoids poor design resulting from changes, thus avoiding a decline in software quality. Therefore, understanding "two hats" and "two hats" is especially important for learning and using system restructuring.

Big talk rebuilding serialization home: http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

Note: I hope that the author or source should be noted to show my respect for the author when I reprint this article. Thank you!