Agile thinking: Methodology in Architecture Design (12)-refactoring

Introduction: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 for guidance.Code. At this time, some problems are often exposed. In actual coding, we usually find that the architecture exists or is 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 each iteration requires
The architecture should be improved.

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
Modify the code without changing the Code's external behavior (observed behavior. We use this term on the architecture model, because the refined and merged architecture model often consists of many coarse-grained components.
There is a certain degree of coupling between these components (although we can make the coupling degree as low as possible, the coupling degree must exist ), the refactoring behavior of any component will spread the changes to other components in the system.
This depends on the relative relationship between the restructured component and other components. If the restructured component belongs to a lower-level tool layer, this modification can cause a great change in the model.

In the refinement and merger model, 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, they find that the initial plan is obvious.
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. Details in this regard
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. Demand spread frequently, probably because users want to add additional
Or, as you learn more about the software, you may find that the original requirements are insufficient. It is impossible to completely prevent the spread of demand, but necessary control is required. For example, effective estimation changes
The impact 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 technical 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 be reduced
The number of architectures to be modeled in a single iteration cycle can reduce errors. On the other hand, the direct result of increasing iterations is the time extension, and there is also a potential problem
Errors in later iterations 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 hierarchical mode) to solve major technical problems. In this process, you can list potential risks in the design, and prioritize the risks based on their likelihood and harmfulness.
Solve these problems. 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 thing 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 types
But if you want to effectively integrate the new system with the old system, the implementation method needs to be well planned. Pay attention to non-functional requirements from the initial iteration process, because if you ignore
They require a lot of effort to adjust the architecture model later. Imagine if the existing database access method in the stress test at the end of the project cannot meet the basic speed requirements of users
How big the impact will be.

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 casting at this time
This 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, delayed Document compilation is not
Do nothing at all. No matter when designing, You need to record the design ideas at will. 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 model is to avoid using the model at the beginning, but to reconstruct the model 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
(Excessive 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
(Examples in refined and merged modes), we will reconstruct the architecture. With the evolution of iteration, the evolution of demand, and the evolution of the architecture, we also need to restructure the behavior at this time. During these processes
The design requires additional flexibility to meet the requirements, so the model needs to be introduced at this time.

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
Due to 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. Such software cannot guarantee its quality.
. 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 feedback.
Currently, high-speed development sacrifices the speed of the future. Poor design requires high-cost maintenance, which will offset the cost saved in the early stage. If the software team needs sustainable development, avoid
This behavior of killing chickens and getting eggs.

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 process of testing first involves writing test cases, and then writing code to complete passing test cases (process details
For more information, 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. Then
And test cases become 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. Avoid this situation.
The method separates the interfaces and implementations of your design model, and enables test cases to target 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 in his application
In the article facade, we mentioned that the facade mode should be used to separate different design parts, while the test should be conducted for facade.

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 relative
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 any
Full testing is impossible. 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 fails to reach
There is no need to use the appearance class to stabilize the effect of the test case.

Only refactor the desired design.

At any time, make sure that the refactoring behavior is only for those designs that require refactoring. Refactoring requires time and effort. Useless refactoring, in addition to increasing the designer's vanity, cannot increase the price for software.
Value. 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 conditions
We should not reconstruct 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 and difficult part of the model. Therefore, we need to document the model, even when necessary,
Train and guide the design. 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. However
When the data is restructured into a pattern, We need to document the data. 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 beginners, the pattern is just like a UFO.
Because of the lack of object-oriented design experience, they cannot understand the processing ideas of the model. In practice, we encounter this situation more than once. We had to begin teaching about models. Therefore, we finally
A certain number of models are used in software design, and 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
Learning curve.

another aspect of pattern consistency is that pattern serves as a bridge for communication. Software development is a kind of team behavior. Therefore, communication plays an important role in software development. Imagine that developers
when discussing 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 with great effort. This will greatly improve the communication efficiency. In addition, the use of the Model
and the reconstruction of the design make sense to improve the programming level of the team and cultivate reserve designers.