Architecture reconstruction improves the design of existing code

(This article is excerpted from the 2010 technology application plan chapter) 

When the architecture model is iterated, the model must be modified and improved. How can we prevent modifications to the model and ensure correct improvements to the model?

　　Context

After the architecture model is refined, merged, and other activities, it will be directly used to guide the code. At this time, some problems are often exposed. In actual coding, we often find that the architecture has large or small problems and errors, leading to the inability to continue encoding activities. At this time, we need to modify the architecture model. The architectural design process is an iterative process, which means that the architecture needs to be improved in each iteration cycle.

　　Problem

How can we avoid modifying the architecture model? How can we ensure that the architecture is correctly improved?

　　Solution

We borrowed a word from XP to describe the refactoring process of modifying the architecture model, which can be translated and reconstructed in Chinese. The term was originally used to describe code modifications. It refers to modifying the code without changing the external code behavior (observed behavior. We use this word in the refined and merged mode, and we mention the differences between change and improvement. Therefore, our countermeasures are mainly divided into two types: how to prevent changes and, use refactoring to improve the software architecture.

　　Prevent changes

Changes to requirements always have the greatest harm to the architecture and software at any time. The biggest problem with demand changes is the spread of demand. Many people feel like this. after the project is completed, it is found that the initial plan is so strange. It is important to control requirements in the early stage of the project, but it is not the focus of this model. We are more concerned with the problem of demand spread in the middle of the project and the problem of demand control in the late stage. For more information, see stabilization mode. In the middle of the project, especially after coding has started, we should try to avoid the spread of demand. The spread of demand often occurs because the user wants to add additional features or, as the user's understanding of the software deepens, finds that there are some shortcomings in the original requirements. It is impossible to completely prevent the spread of demand, but necessary control is required. For example, effectively estimate the impact of changes on development, testing, documentation, management, and organization.

Another effective way to avoid changes is to start with the software process. Iterative Methods or progressive delivery methods are available. The architecture design of a software is often relatively complex, involving the overall structure, specific technology and other issues. When all the elements are taken into account at one time, it is very easy to consider the case that you are not careful. Human Brain capacity is not as big as we think. The architecture design is divided into multiple iteration cycles for progress, which can reduce the number of architectures to be modeled in a single iteration cycle, and thus reduce the occurrence of errors. On the other hand, the direct result of increasing iterations is time extension. In addition, there is another potential problem. If problems occur in later iterations due to designer errors, this will inevitably lead to a lot of rework. Because the previous model has been implemented. How can we find a proper balance between gains and losses?

The number of iterations should be determined based on the characteristics of different software organizations. For the initial iteration cycle, its main task should be to develop general principles (using the Architecture Vision Model) define the layer structure and responsibilities of each layer (using the hierarchical mode) to solve major technical problems. In this process, you can list possible risks in the design, and prioritize the risks based on their likelihood and harmfulness, and designate a designated person to solve these problems in order. In addition, in the initial stage, it is important to refer to the experience of the previous project for the team to design (see the team design model. The initial iteration process is the most important activity to prevent changes.

Pay attention to the non-functional requirements in the requirement. If the functional requirement defines the architectural design goal, the non-functional requirement limits how to achieve this goal. For example, there are multiple methods to implement a report. But if you want to effectively integrate the new and old systems, you need to plan the implementation method well. Pay attention to non-functional requirements from the initial iteration process, because if you ignore them, it will take a lot of effort to adjust the architecture model later. Imagine how much impact the project would be caused if the existing database access methods fail to meet the basic speed requirements of users during the stress test at the end of the project.

Pay attention to the stability of the architecture. In the refined and merged mode, we mentioned some modes that can reduce the Coupling Degree between different components. And hide the specific implementation from the caller. Separation of interfaces and implementations is the biggest feature of the design pattern. Please make good use of this.

Extend the preparation of formal documents as much as possible. In the initial stage of design, modifying the model and writing documents usually do not make much sense. Because the model is not stable at this time, it must be constantly modified. If you start to develop documents at this time, it means that a task to maintain document consistency will be added in the subsequent iteration cycle. At this time, the document cannot play its real role. However, writing delayed documents does not mean that you do nothing. You need to record the design ideas at any time. In this way, we can have sufficient materials to document the design as needed.

　　Rebuilding the software architecture

Martin Fowler's refactoring book lists a series of code refactoring methods. The architecture is similar.

Reconstruction to Mode

Joshua kerievsky describes the relationship between refactoring and pattern in refactoring to patterns:

Patterns are a cornerstone of object-oriented design, while test-first programming and merciless refactoring are cornerstones of Evolutionary Design

(Pattern is the cornerstone of object-oriented design, while test-first programming and relentless refactoring are the cornerstone of design evolution ). The author emphasizes the importance of maintaining a moderate design.

In the author's opinion, patterns often play the role of over-design. While solving this problem, the solution that utilizes the advantages of the pattern is to avoid using the pattern at the beginning, but to reconstruct the pattern in the design evolution. This approach is very effective, because when you use patterns in the initial design, your attention will be focused on how to use patterns, rather than how to meet your needs. This will lead to inappropriate design (over-design or inadequate design ). Therefore, in the initial design, unless we are very confident (with similar experience), we should focus on how to meet the needs. After the initial model is complete (see the example in finalize and merge mode), we will reconstruct the architecture. With the evolution of iteration, the evolution of demand, and the evolution of architecture, at this time, we also need to reconstruct the behavior. In these processes, if you find that some parts of the design requires additional flexibility to meet the requirements, then you need to introduce the model.

In the process of software development, we often encounter scenarios where the design is inadequate. For example, the coupling between components is too high, and the business layer exposes too many methods to the client. In many cases, this phenomenon is caused by unrealistic plans. Developers have to rush to work for the deadline, all the time is spent on new features, and the finished software is still on the sidelines. The quality of such software cannot be guaranteed. In this case, we also need to reconstruct the design. Of course, a reasonable plan is the premise. The team leader must explain to senior managers that the current practice will only lead to future rework, and the current high-speed development is at the cost of sacrificing the future speed. Poor design requires high-cost maintenance, which will offset the cost saved in the early stage. If the software team needs to be sustainable, avoid this kind of behavior.

Therefore, pattern is used to help refactor behavior to achieve proper design.

　　Test Behavior

The premise of refactoring is testing first, and testing first is an important practice in XP. For coding, the test-first process is to write test cases and then write code to complete the test cases. (For more information about the process, see related XP books ). However, for architecture design, the test behavior occurs after the design, that is, after the design model is complete, the corresponding test cases are generated and then encoded for implementation. At this time, the test case becomes the link between architecture design and coding activities.

On the other hand, when the design is restructured, the corresponding test cases are also highly likely to change. In this case, the test code that needs to be changed exceeds the normal code. One way to avoid this is to separate the interfaces and implementations of your design model, and enable the test cases to be specific to the interfaces instead of implementations. In the Finalize and merge modes, we have mentioned some patterns that can help design and test cases stably. Martin Fowler mentioned in his article Application facade that the facade mode is used to separate different design parts, while the test should be conducted for the facade. The same is true for the idea.

Consider a user transfer case. The bank must first review the user's permissions and allow the transfer only after the review is passed (for convenience, the creation process and call parameters of the object are ignored in the figure ):

Test cases need to be written for three categories respectively. Once the design model changes, the test cases need to be rewritten. Consider the following situation:

The current design introduces the transferfacade object, so that our test cases can be compiled for transferfacade, And the transfer business logic is relatively stable. When using this test method, pay attention to two points: first, this does not mean that other classes do not need test cases. This test method only focuses on the appearance class, because full testing is impossible at any time. However, testing of other classes is also necessary. For appearance classes, errors in any business method will lead to the final test failure. Second, when the appearance class test cannot achieve the stable test case effect, there is no need to use the appearance class.

　　Only refactor the desired design.

At any time, make sure that the refactoring behavior is only for those designs that require refactoring. Refactoring takes time and effort, while useless refactoring does not add value to software unless it increases the designer's vanity. The reconstruction needs to come from two points: first, the demand change. The current design may not meet new requirements, so reconstruction is required. The second is to improve the design to achieve excellent and concise design. In addition to these two cases, we should not refactor the design model.

　　Use the document record reconstruction mode.

It should be acknowledged that the pattern provides sufficient flexibility for the design. These designs are often the key points and difficulties of the model. Therefore, we need to document the model, and even train and guide the design when necessary. Make sure that your team can use documents correctly to design, understand, and expand the model. We mentioned in the previous section of the solution that we try to delay document creation. When the design is restructured into a model, we need to document the work. Because the model is flexible, it can resist certain risks of changes.

　　Rebuild and maintain pattern consistency

As mentioned in the previous section, a pattern is not easy to understand, although it maintains design flexibility and stability. For new object-oriented users, the pattern is just like a UFO. Due to lack of object-oriented design experience, they cannot understand the pattern processing ideas. In practice, we have encountered this situation more than once. We had to begin teaching about models. Therefore, we finally adopt a certain number of models in the software design, and ensure that the same model is used to handle the same problem. In this way, the application model becomes a standard practice for solving a certain type of problems, thus reducing the learning curve to a certain extent.

Another aspect of pattern consistency is that pattern serves as a bridge of communication. Software development is a kind of team behavior. Therefore, communication plays an important role in software development. Imagine that when developers discuss software design, they only need to say "using the factory model", so that everyone can understand it, rather than explaining the relationship between several classes. This will greatly improve the communication efficiency. In addition, the use of the model and the reconstruction of the design are of great significance for improving the team's programming level and cultivating reserve designers.