Eleven, refactoring
When the architecture model is an iterative process, it is inevitable to modify and improve the model. How do we prevent modifications to the model, how to ensure the correct improvement of the model?
Context
After the architecture model is refined, after the merger, it will be used directly to guide the code. At this time, it is often exposed to some problems, usually in the actual coding, found that the architecture exists or small problems and errors, resulting in coding activities that cannot continue. At this time, we need to modify the architecture model. The process of architecture design is an iterative process, which means that the architecture needs to be improved during each iterative cycle.
Problem
How do we avoid modifying the architecture model? How to ensure the correct improvement of the architecture?
Solution
We borrow a word in XP to describe the modification process of architecture model - Refactoring, Chinese can be translated as reconstruction. This word is originally described to modify the code. It refers to modifying the code without changing the code external behavior (observable behavior). We use this word on the architecture model because the architectural model after being refined and combined is often composed of many coarse particle size components. There is a certain coupling between these components (although we can make the coupling as low as possible, the coupling degree must be present), and the reconstruction behavior of any component will make the change to other components in the system. This depends on the relative relationship between the reconstructed components and other components. If the reconstructed component belongs to the lower hierarchy tool layer, then this time the modification can cause a large change in the model.
In the refining and merge mode, we mentioned the difference between change and improvement. Therefore, our countermeasures are mainly divided into two types: how to prevent changes in changes, and use reconstruction to improve software architecture.
Preventing changes
At any time, changes in demand always have the biggest damage to the architecture and software. The biggest problem in demand changes is the spread of demand. Many people have such a feeling. After the project is completed, the initial plan is so unfamiliar. It is important to control demand early in the project, but it is not the focus of this mode. We are more concerned about the demand spread in the mid-project demand spread and advanced demand control issues. For a detailed discussion in this regard, see Stabilization Mode. In the middle of the project, especially after the coding work has begun, it is necessary to avoid the situation of demand spread as much as possible. The spread of demand often occurs, probably because users want to join additional function, or with the user's deeper understanding software, found that the original demand has certain shortcomings. It is impossible to prevent demand spread, but it needs to be controlled. For example, effective estimation changes have the impact on development, testing, document, management, organization, and the like.
Another effective way to avoid changing is to start from the software process. Iterative or gradual delivery methods are available. A software architecture is often relatively complicated, including problems such as overall structures, specific technologies. Considering all elements at one time, it is easy to consider unwanted situations. The human brain capacity is not as big as we think. The architecture design is divided into multiple iterative cycles, which can reduce the number of architectures that require modeling in a single iterative period, so errors can be reduced. On the other hand, the number of the number of iterators is the extension of time, and there is a potential problem. If the designer's mistake, problems occur in later iterations will result in a large number of rework. Because the previous model has been implemented. How do we find the right balance between you?
The number of iterations should be developed according to the characteristics of different software organizations. For the initial iterative cycle, its main task should be the development of the general principles (using the architectural vision mode), define the responsibility of the layer structure and layers (using hierarchial mode) , Solve the main technical issues. In this process, you can list the risks that may be encountered in the design, and schedule priority according to the possibility and harm of risk, specifying a special person to solve these problems in order. In addition, in the early experience of the previous project, the team is designed (see team design mode), which is also important. The initial iterative process is to prevent the most important activities of changes. Please note the non-functional needs in the demand. If the functional demand defines the target of architecture design, non-functional requirements make limit on how to reach this goal. For example, for a variety of operational methods that implement a report, if the user wants a new system and the old system to effectively fuse, the implementation requires a good plan. Please pay attention to non-functional requirements from the initial iterative process, because if they ignore them, it takes a lot of energy to adjust the architecture model in the later stage. Imagine that if in the pressure test of the project, discovery that existing database access methods cannot meet the basic speed requirements of the user, how much impact will be made to the project.
Pay attention to the stability of the architecture. In the refining and merge mode, we mentioned some modes to reduce the coupling between different components. And hide the specific implementation to the caller. Interfaces and implementation is the largest feature of design patterns, please use this.
Deverse the preparation of the official document as much as possible. In the early days, modified models and writing documents are usually not too significant. Because the model at this time is still unstable, it is necessary to constantly modify it. If this time begins to invest in the development document, this means that the subsequent iterative cycle will increase the work of maintenance document consistency. And the document at this time cannot play a true role. However, the writing of the delay document is not equal to anything, no matter when designing, it needs to record the idea of design. In this way, we can have a full information to document the design.
Reconstructing software architecture
The Refactoring Book of Martin Fowler lists a series of reconstruction methods for code. The architecture is also similar.
Reconstruction to mode
Joshua Kerievsky describes the refactoring and modes of the Refactoring to Patterns.
Patterns Are A Cornerstone of Object-Oriented Design, While Test-First Programming and Merciles Refactories in Cornerstones of Evolutionary DESIGN
(The mode is the cornerstone-oriented cornerstone, and test priority programming and ruthless reconstruction is the cornerstone of design evolution). The author emphasizes the importance of maintaining moderate design in the text.
In the author's view, the model often plays excessive roles. The solution to the advantages of using the pattern while solving this problem is to avoid using the mode in the beginning, but refactoring to the mode in the design evolution. This approach is very effective, because in the initial design use mode, your attention will focus on how to use, rather than concentrated how to meet demand. This will result in inappropriate design (excessive design or insufficient design). Therefore, in the initial design, we should put energy in how to meet the needs unless there is very grasp (previously similar experience). After the initial model is completed (see Examples in Refining and Merger), we will reconstruct the architecture, and with the evolution of iteration, the demand evolution, the architecture also needs evolution, and the architecture also needs to be reconstructed. During these processes, if you find that some parts of the design require additional flexibility to meet the needs, then you need to introduce mode. In the process of software development, we are more often in the case where the design is not sufficient, such as the coupling between components, and the business layer exposes excessive methods to the client. Many times, this phenomenon is caused by unrealistic plans. The developers have to be driven in the end term, and all the time spent on new features, while the completed software is still on the side. The software that outputs this cannot guarantee its quality. In this case, we also need to redeem, of course, the reasonable plan is the big premise. The team's leader must explain to the senior manager, and now this practice will only lead to future rework, and the current high-speed development is at the expense of the future. Because of the high cost maintenance required for poor design, this will offset the cost of the previously saving. If the software team needs sustainable development, then avoid this kind of behavior of killing chicken.
Therefore, use mode to help reconstruct behavior to achieve proper design.
Test behavior
The premise of reconstruction is that test priority is a very important practice in XP. For coding, the test priority process is to write test cases, and then write code to complete the test case (not only the details, please see the related books of XP). However, for architectural design, test behavior is after design, that is, after the design model is completed, the corresponding test case is output, and then the implementation is reused. At this time, the test case has become a link for contact architecture design and encoding activity.
On the other hand, when the design is reconstructed, the corresponding test case is also changed by a large possibility. At this time, the test code that needs to be changed is exceeded by normal code. Avoiding such a situation is to separate the interfaces of your design model and achieve phase separation, and make test cases to interface instead of implementation. In the refining and merge mode, we mentioned some models that can help stabilize design and test cases. Martin Fowler In his Application Facade, it refers to the use of the FACADE mode to separate different design sections, and the test should be made for Facade, and the idea is true.
Consider the use case of a user transfer. Banks need to review the user's permissions and allow transfer after the audit is passed (in the simple origination, ignoring the creation process of the object and call parameters):
It is necessary to write test cases for three classes. Once the design model changes, the test case will need to be rewritten. Consider the following cases:
The current design introduces TransferFacade objects so that our test cases can be written for TransferFacade, while the transfer of business logic is relatively stable. When using this test idea, pay attention to two points: First, this is not to say that other classes do not need test cases. This test idea is just putting the test focused on the appearance, because of any time Test is impossible. But other classes are also necessary. For appearance, the error of any business method will result in the final test failure. Second, when the test of the appearance cannot reach the effect of stabilizing the test case, it is not necessary to use the appearance. Refactoring only for designs required.
At any time, make sure that the reconstruction behavior is only designed for those who have reconstructed needs. Refactoring requires time and effort, and useless reconstruction does not increase value for software in addition to increasing the vanity of designers. Reconstruction needs to be from two points: one is the change of demand. The current design may not meet new needs and therefore need to be refactored. The second is to improve design to get excellent and simple design. In addition to these two cases, we should not reconstruct the design model.
Use the document record reconstruction mode.
It should be acknowledged that models provide a full flexibility for design. These design parts are often the critical and difficulties of the model, so it is necessary to document the model, even if necessary, training and guidance for this part. Make sure your team can design, understand, and extend the mode correctly. We mentioned the creation of the document as possible in the previous section of the solution. When designing is moderate, we need to work in documentation. Because the mode is flexible, it is resistant to a certain change risk.
Reconstructing and maintaining consistency
As mentioned in the previous section, the pattern is not a very easy to understand, although it maintains the design flexibility and stability. For object-oriented newcomers, the mode is simply like a UFO. Due to the lack of object-oriented design experience, they cannot understand the mode of processing, in practice, we don't just meet this situation. We have to go to teach professors about models. Therefore, finally we use a certain number of patterns in software design and ensure the same mode when processing the same problem. In this way, the mode of the application becomes a standard approach to solving a problem, thereby reducing the curve of learning to a certain extent.
Another aspect of another aspect of the consistency of the maintenance mode is the bridge of the communication as a communication. Software development is a team's behavior. Therefore, communication plays an important role in software development. Imagine that when the developers are discussing software design, they only need to say "using factory models". Everyone can understand that the relationship between several classes is instead of the tongue. This will greatly improve the efficiency of communication. In addition, the reconstruction of the use and design of the model is meaningful for increasing the team's programming level, and cultivating the designers of the reserve.
