Refactoring a true lie in serialization

After the previous explanation, I believe you have some preliminary understanding of the system reconfiguration. Everything seems to tell us that system refactoring always has nothing to do with changing requirements. But at this point, I have to tell you this is a true lie.

Our software system is always in a change, and often is a process from easy to difficult. However, when the complexity of the system changes, we should adjust our design in time to adapt to the new changes. However we did not do this, so our system maintenance becomes more and more difficult. To solve our problems, we must optimize our programs to adapt to our business needs through system refactoring. There is no doubt that the change in requirements is the main reason for us to refactor.

However, system refactoring requires that we do not change the external behavior of the software, which means that you cannot add any new functionality to the software during refactoring, and refactoring seems to have nothing to do with changes. This is a bit confusing, we try to refactor because of the change, but the refactoring doesn't let us change it! The key to cracking this true lie is that system refactoring does not prohibit us from changing, but should be changed in a "two hats" way.

What is "two hats"? When we need to change the system, we should divide the process of change into two steps: first, to refactor our systems to adapt to new requirements without adding any functionality, and then start to change to meet new requirements. The first step is what we call refactoring, which ensures that the original function is correct, and that the system structure can adapt to new requirements. In order to achieve this goal, we allow refactoring to be done without changing the external behavior of the software, only to adjust its internal structure, and to keep the external functionality unchanged. When the internal structure of the software can adapt to new requirements, we begin to add new features, the logical implementation of new requirements.

You might ask, why is it so complicated? Let's analyze how we used to add new features. When users come up with a new requirement, the first principle of our code is to modify the new requirements without affecting the previous functionality. How did we do that in the past? In fact, we do not have any good way, an intuitive idea is that the original code to change less, the smaller the amount of change, the risk of modification error will be the smallest. Because of this, even if the original program has not adapted to the new requirements, but the programmer is unwilling to modify the structure of the program, but the existing code continues to add programs. With the passage of time, adding more and more programs, more and more chaotic, so the system maintenance costs more and more high.

Using System refactoring is not such a concept at all. Here when the original program does not adapt to the new requirements, our strategy is a "poor design 0 tolerance" strategy, that is, first refactoring the system to adapt to the new requirements first, and then smoothly to achieve these requirements. As "do not change the external behavior of software", we can easily set up test mechanism, under the constant supervision of the testing mechanism, to ensure the success of refactoring quality. We can then implement new features that are easy to implement and ensure readability, maintainability, and ease of change. This process avoids the bad design caused by the change and avoids the software quality decline. Therefore, understanding the "two hats", the habit of "two hats", for learning and the use of system reconstruction, it is particularly important.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/