Turn: understanding of System Restructuring

What is refactoring?
Restructuring: it is necessary to re-adjust the internal structure of the system without changing the system functions. The most direct purpose of refactoring is to improve the internal architecture of the software system. A good structure can better adapt to changes in requirements, better meet customer needs, and maximize the life cycle of the software system.
Why rebuild
Without changing the system functions, you can change the system implementation mode. Why? The effort is not enough to meet the customer's needs, but only changes the implementation method of the software. Is this a waste of the customer's investment?
The importance of refactoring begins with the software life cycle. Software is different from ordinary products. It is an intellectual product with no specific physical form. The physical loss of a software is impossible, and the buttons on the interface will never lead to poor contact because of too many clicks. So why can't a software be used forever after being manufactured?
There is only one factor that threatens the life of software: Change of demand. A software is always generated to solve a specific requirement. The times are evolving and the customer's business is changing. Some demand is relatively stable, some demand changes dramatically, and others have disappeared or transformed into other demands. In this case, the software must change accordingly.
Considering cost, time, and other factors, not all demand changes must be implemented in the software system. But in general, the software must adapt to the changes in demand to maintain its own vitality.
This led to a bad phenomenon: software products were originally manufactured and carefully designed with a sound architecture. However, with the development of time and demand changes, you must constantly modify the original functions and add new functions. There are also some defects that need to be modified. To achieve changes, it is inevitable to violate the original design architecture. After a while, the architecture of the software was broken. More and more bugs, more and more difficult to maintain, more and more difficult to implement new requirements, software architecture for new needs gradually lose support capabilities, but become a constraint. At last, the development cost of the new requirement will exceed the cost of developing a new software. This is the end of the software system.
Restructuring can avoid such a phenomenon to the maximum extent. After the system develops to a certain stage, it only reorganizes the internal structure without changing the external functions of the system. Through restructuring, the system structure is constantly adjusted, so that the system can always adapt to changes in demand.
Reject changes vs embrace changes
According to the traditional software design method, the software production can be divided into the following stages: requirement investigation, outline design, detailed design, coding, monomer testing, joint testing, and on-site deployment. Although these stages can penetrate each other, there is a certain order in general. The work of the previous stage is the basis of the work of the next stage. This is similar to the following V-shaped mode:

The system is decomposed in the next direction, and the system is integrated in the next direction. In this way, software development is divided into two stages: Pre-Design and post-design. There is an important "Milestone" in the development process-the Design Manual. Before the design specification is completed, the project is in the "design" stage, and after the design specification is completed, the project enters the "Implementation" stage. Once the implementation stage is reached, any requirement or design change is very difficult and requires a lot of cost. To ensure the smooth implementation of the project, developers often have the impulse to hold down the customer's hand and sign the demand statement. And told the customer: "from today on, any demand change will be stopped until we finish the current thing ." This is a development method that rejects changes.
The software system should be consistent with the enterprise's goal. The times are evolving, people's requirements are constantly improving, and customers' businesses are constantly evolving. In this case, the traditional V-shaped design and construction cannot meet the increasingly complex business needs. Software Engineering has evolved into the following process:

Note:
1. The goal of software development should be consistent with that of the enterprise. A development cycle should not be too long. Generally, it should be set to six months to one year. After the system is deployed, it does not mean that the development is over, but enters the next cycle.
2. The project advances in a Circular Iteration. This does not mean that the design is ignored. It is not a "three-way" project that requires research, design, and construction. On the contrary, is more emphasis on design. The whole process of software development needs to be designed, and software development is a process of "continuous design. At the same time, the design work is not only simple process decomposition, task allocation, but also conceptual design, logical design, physical design and other aspects of the intertwined, go hand in hand.
Traditional software development methods use a very idealized process-first, discuss the scope of the project with the customer, determine what needs to be done and what does not need to be done, and then plan a perfect design, it not only meets the current needs, but also well adapts to future needs. After the design is complete, code is started, and then tested and assembled, and delivered to the site for installation, debugging, and operation. This process is similar to launching a shell. First, you need to find the target, and then calculate the advance volume and shell launch Angle Based on the terrain, wind power, target location, moving speed, and other factors, calculate a Parabolic orbit, and finally launch shells at the right time. All of this is in line with the most correct law of physics, and everything sounds ideal. If there are no unexpected conditions, you can certainly hit the target. However, once a shell is fired, everything is out of control, and any change in the environment will lead to a deviation from the target. Especially for a moving target, the computing process is very complex and can only be estimated by people in many cases. For irregular sports goals, you can only try your luck. In this way, the hit rate is very low.
The new software development process does not pursue a perfect, long-term, and ideal plan. It attaches more importance to actual conditions, changes in requirements, and advocates the adoption of short-term plans. This is a process of embracing change. It is like installing a feedback device on the shell. After the target is locked, make sure that the direction is correct, and then launch the shell. During the running process, shells continuously input the target position offset into the feedback circuit, and adjust their own running routes based on the feedback output to infinitely approach the target. In this way, shells have the guidance capability, and the hit rate is greatly increased.
Reconstruction can increase the engineering adjustment capability. It can restore the product to a stable State and achieve the next goal based on this state. This process is repeated to better meet customer needs.
Maintain compatibility
The purpose of restructuring is to change the implementation method of the system without changing the original functions. In this process, it is very important to judge compatibility. Whether a sub-system, module, class, and function are compatible with the pre-upgrade. How to judge the compatibility and maintain the compatibility is related to the reconstruction cost and the possibility of reconstruction.
Program Members learn to write programs Code As program code grows, many program codes are repeatedly appearing and used, therefore, it is natural to start using routines, subprograms, processes, functions, and other mechanisms to help us organize program code. Naturally, the font Analysis Method evolved into this: the customer's demand process is decomposed step by step until it can be directly implemented. This is a process-oriented analysis method.
The process-oriented analysis method is weak in changing capabilities. Why? Because the process-oriented analysis method can easily lead to a tendency-not to differentiate the subjects of action. There is no subject in a process. He is not working for himself, but for "others. After we modify a process, it is difficult to determine whether the process is backward compatible and whether other processes will be affected. This process makes sense to the outside world not only for its input and output, but also for each step. Each step may contain a very vague business meaning and have an impact on the outside world.
Therefore, it is very difficult to modify a process. Generally, you can upgrade a process-oriented system in two ways:
1. Write a new process;
2. Add the switch parameter in the original process.
In addition, it is difficult to ensure the compatibility between the original process and the new process, which may cause errors.
To better ensure the compatibility of the upgraded modules, we should adopt an object-oriented analysis method. According to this analysis method, an object is "self" and has a complete and independent business meaning. An object is linked through an interface. Only interfaces are affected by an object. It is not a matter of concern to the outside world as to what it does, how it is done, and whether it is correct.
It is easy to determine whether an interface is compatible after upgrade. We can determine whether the input and output of the interface comply with the following two rules:
1. Input after upgrade is the Super input before upgrade;
2. The output after the upgrade is a subset of the output before the upgrade.
As long as these two points are met, the system can still run in the system, without causing harm to other objects. In actual projects, there is a better way to judge this compatibility: Automated Unit Testing .
In the reconstruction process, automated unit testing is a very good guarantee. Automated unit testing and continuous testing can ensure that the business behavior does not change during the system structure change.