Twelve, stabilization
The rise of agile methods has made new requirements for the design, and the core of its core is to evolve the demand for curing in the beginning of the project. In the beginning of the project, the accurate architecture design becomes more and more difficult, so the architecture design has been continuously improved in the progress of the project, which has led to instability of the coding, testing and other activities. However, the software must ultimately be delivered in a stable code. Therefore, architectural design must experience the process from unstable to stable. The premise of architectural design can be stable in demand.
Demand freeze
The difference between agility methods and conventional methods is to treat changes. Traditional practices are sufficient, meticulous demand research and design work before the coding activity begins, and sign the contract. Ensure that all the previous work has been completed, starting coding, testing, etc. If there is a case where demand changes, strict controls are required. In reality, this approach often causes problems in the previous period in the previous period of the project due to inconsistencies of developers and customers, and the demand itself. The result is either to reject the demand, which makes the customer's interests, or it is deducted from demand changes to the project out of control. The agile method is different, it emphasizes hug changes. For the variable demand, it uses a series of practices to tame this kind of horses. Its core is iterative development. It should be acknowledged that it is not an easy thing to master the needs, and iterative development is also easy to bring additional high costs to the development team. To do this, there is a need for other practices (mentioned below). Therefore, we need to freeze the demand when it is an iterative development to a certain stage. At this time, the demand frozen and the beginning of the above start will not be the same. First, after the user has experienced one or several iterations, the software development already has an image of the image, and it is no longer a fog to see if the demand is no longer fog. Secondly, by utilizing practices such as prototype law, users may even have certain experiences on the final form of software. In this way, the demand proposed by the user can basically represent their true needs. Even if there is also a modification, it will not have a bad impact on the architecture of the software. Finally, it is often in the medium term of the project, and if the demand is still unstable, the final success of the project is difficult to guarantee.
Before the demand is frozen, do not put energy into the production of the document, the correct approach is to keep the information that should be in order to complete the document later, not when the demand is undefined, requires a beautiful format. Documentation. It is easy to spend a lot of time on the formatting document, and if the demand changes, all investment is wasteful. The input of documents should increase as the project. But this is no means not to say that the document is not important, because you have to keep enough information to ensure that the document can be created smoothly.
Make sure there is a special person to accept requests for change needs, which ensures that changes in demand can be controlled. This work can be responsible by the project manager (or similar role) or by the following changed committees. Small, scattered demand is easy to have an impact on developers, and they have more important tasks - advance the project forward. At this time, the project manager is like a buffer, which is determined by the classification, priority, workload of the demand, and schedule a plan to change the existing software, thereby planning a plan for a change - it is completed in this iteration , Is still completed in the next iteration.
Establishing a Demand Change Commission is a good practice that is composed of different types of projects, which may include management, development, customer, documentation, quality assurance, etc. They make assessment and decisions for demand changes, assess demand for fees, progress, and impact of all aspects, and make decisions on how to accept demand. Since the Committee tends to involve the entire project team, efficiency may become its main drawbacks. In this case, on the one hand, it is possible to strengthen the management of the committee, and on the one hand, it will ensure that the Committee only handles large demand changes.
At different times of the project, you need to have a different degree of demand, which sounds some contradictions with the changes in the hugs we advocate. actually not. The main purpose of constraints to demand is to prevent the demand expansion and spread, avoid unrealistic functions. We can often mention, such as "This feature is cool, our software should also include it" and "our opponents have developed this feature, the final software must include this function". This is a sign of typical demand spread. The correct estimation functionality at the beginning of the project is controlled in the middle of the project, and the advanced demand is eliminated in the middle of the project. Three ways to ensure that the software can be launched. Stable architecture
Even if the demand has been frozen, we still face an unstable architecture. This is inevitable, and the degree of unstable and the ability of the team and the degree of understanding of the target areas. Therefore, the architecture also needs to be improved. In the previous mode, we discussed the reconstruction of the architecture, in fact, this is a way to stabilize the architecture. Experience data shows that a series of small changes are easier to achieve more than a large change, and it is more easier to control. Therefore, in the iteration, the scheme is constantly reconstructed, and it seems to be slowed down, but it lays the foundation for the stability of the software architecture. Reconstructing the way of thinking, that is, the function increases in this period, the next time period is adjusted, the two time periods will never repeat, and the structural improvement is not considered when the function is increased, in the improved structure There is also an increase in the function of functionality. After the architecture is moved to stabilize, its main responsibilities will also become improved to the structure. From its own experience, this stage is very important, improved software quality, has a great help to deepened project members' awareness of the target field. At this stage, it is also easy to extract universal architectures so that software organizations are accumulated.
In this stage, the experienced architect or advanced programmer is very good. This approach comes from the practice of software review. Whether it is improving software quality or improving project member qualities, it is very helpful.
The structure of architecture is implied with a stability of development methods. Programmers often like new technologies, new tools. This is unclear. But in the project, new technologies and new tools are always risky. There may be some problems with the tools that the manufacturer's tools have not been resolved, or the technology is not very good for the original version. These will have a bad impact on the project. Therefore, if new technologies and new tools must be adopted in the project, it is necessary to arrange time to familiarize new things in the initial stage of the project. Before the architecture enters stability, the tool usage, technical method must have completed the test, and has been completed to all members. Otherwise, we must do a trade-off between extending time and abandoning the use of new things.
Guaranteed outstanding practice
At the beginning of the article, we talked about that the exact, detailed architectural design was unrealistic in the project initial stage. Therefore, there are many practices in agile methods to stabilize the initial architecture design. In fact, these practices are not a new concept proposed by agile methods. Agile method only organizes these relatively excellent practices, providing a guarantee for stable architecture design. Here we discuss these practices in detail.
Signancy in an unstable environment. What is stable, what is unstable. RUP recommends architectural design using a business entry method. One of the benefits of this method is to be relatively stable by identifying a business entity to establish an architecture. Because business entities belong to a stable element in unstable business logic. Everyone can imagine, the company, employees, and departmental concepts have not changed too much decades. The same is true for a particular business. For example, for accounting generals, subjects, balances, subscribers accounts, original vouchers, these concepts have never changed much, and their corresponding behavior is not much different. But some business logic is completely opposite. Different system business logic is different, and different timepoint business logics may also change. For example, for different manufacturing industries, most of its cost accounting is different. Even if the industry is the same, the business logic has no commonality. Therefore, the stable architecture design should depend on the stable basis, for unstable factors, better practice is to abstract, abstract stable things, and package unstable factors in a separate position, to avoid its The effect of other modules. The direct results of this idea are the practice of the next paragraph to interface programming. For example, for the cost accounting mentioned above, although they are volatile, unstable, they still have stable things, which is that most manufacturing companies need cost accounting. This is very important, so that the interface method is relatively fixed. Another way to maintain architecture stability is to adhere to the design method for interface-oriented programming. We mentioned the design method for interface programming, encouraged abstract thinking, concept thinking. From the example mentioned in the hierarchical mode (see the interface programming section of the hierarchical mode), we can see that a large role of the interface is to be able to group class features to avoid client programs. Refers to understand and not relevant knowledge. The design mode is very emphasized in the interface and implementation, and the main form of performance is exactly. The customer programmer does not need to know the specific implementation. For them, it is only necessary to clear the way the interface is available.
From another aspect, the interface is to be separated, because the interface is a relatively stable portion in the demand, and the implementation is associated with a specific environment. The figure below shows the method published by the Collection interface in Java. It can be seen that at this level, the Collection interface is only some stable ways depending on the characteristics of the container. For example, increase, delete, compare operations, etc. So this interface is relatively stable, but for specific implementation classes, the details of these methods are different. For example, for a List and an Array, they are not the same for increasing, deleting implementations. But for customer programmers, what do they do with understanding the ADD method for the List and Array's add-on method unless there is a need for the underlying implementation. On the other hand, these methods are implemented as fixed, universal interfaces, and also facilitate the developer of the interface. They can separate the implementation and interface, in addition, other software development teams can also develop a combination of applications as long as they meet these published interfaces. In the current environment where you are currently working, the efficiency is about. This development method is very important.
java.utilInterface Collectionbooleanadd (Object o) booleanaddAll (Collection c) voidclear () booleancontains (Object o) booleancontainsAll (Collection c) booleanequals (Object o) inthashCode () booleanisEmpty () Iteratoriterator () booleanremove (Object o) booleanremoveAll (Collection c) BooleanRetainal (Collection C) INTSIZE () Object [] Toarray () Object [] TOARRAY (Object [] A) Reconstruction. Code reconstruction is another method that tends to stabilize the architecture. In terms of concern, refactoring should be a personal quality of programmers. But in practice, we found that reconstructing this behavior is more suitable as a common behavior of development teams. Why do you say this? When I was the earliest contact concept, I didn't know how to object-oriented. Therefore, the concept of reconstruction does not catch a cold. But with the accumulation of experience, object-oriented thinking. I gradually discovered that reconstruction is a very good code improvement method, which improves the effect of the software architecture by improving the quality of the code by working atomic operation. When the programmer gradually skilled the reconstruction, he no longer stabilized in these atomic operations, but naturally wrote outstanding software. This is an improvement in the actions of each person. On the other hand, for a team, each person's programming level and experience are different, so the quality of each module of the software is also uneven. In this case, the improvement of software quality is no longer a personal problem, and the difficulty of this problem is much larger than the previous problem. At this time, the reconstruction method is more powerful. Advocate in the team, even semi-strong use reconstruction, help to share excellent software design ideas and improve software overall architecture. At this time, the reconstruction is not only limited to the improvement of the code (referring to the various methods mentioned in the reconstruction of the book), and it also involves the application of analytical model, design mode, excellent practice. At the same time, we should also see that the reconstruction requires cooperation with other excellent practices. For example, code review and test are preferred.
to sum up
Factors that tend to stabilize the architecture include two aspects of the need for freezing and architecture improvement. Demand freeze is prerequisites that the architecture improvement is an inevitable step. In object-oriented areas, we can maintain a stable architecture through some practical skills. These practice techniques are embodied in the process of analyzing the code from demand. Stabilization mode and the next code verification mode have a lot of associations, and we will discuss in the next article.
