Agile thinking: Methodology in Architecture Design (13)-Stability

Introduction:The rise of Agile Methods puts forward new requirements for design. The core of agile methods is to carry out performance-oriented demands that cannot be fixed at the beginning of the project.
Design. It is increasingly difficult to design a detailed and accurate architecture at the beginning of the project. Therefore, the architecture design is constantly improved in the progress of the project, this leads to unstable coding, testing, and other activities. However,
The software must eventually be stableCodeFormat delivery. Therefore, the architecture design must go through a process from unstable to stable. The premise of stable architecture design is the stability of requirements.

Demand freeze

The difference between agile methods and traditional methods lies in their attitudes towards changes. The traditional approach is to carry out full and meticulous demand research and design work before the coding activity starts, and sign the contract. Make sure all the preliminary engineers
Coding and testing are started only after all operations are completed. If the demand changes, strict control is required. In reality, this method is often due to the needs of both developers and customers.
The inconsistency of solutions, the variability of requirements, and other problems lead to the project's initial needs being completely solidified and become unrealistic. The result is either a rejection of a change in demand, compromising the customer's interests, or a submission to a change in demand.
The project is out of control. Agile Methods are different. They emphasize embracing change. It uses a series of practices to combat the changing needs. Its core is iterative development. It should be admitted that it is not necessary to grasp the requirements
It is easy, and iterative development can easily bring additional high costs to the development team. To achieve this, we need to cooperate with other practices (as mentioned below ). Therefore, in iterative development
The demand is frozen. At this time, the demand freezing is different from the above mentioned requirement fixing at the beginning. First, after one or several iterations, the user has
Image recognition, the need is no longer confused. Secondly, by using the original method and other practices, users may even have some experience on the final form of software. In this way, the user's requirements can basically represent
Their real needs. Even if there are still modifications, it will not have a bad impact on the software architecture. Finally, the demand freezing point is often in the middle of the project. If the demand remains unstable at this time, the project's final success
It is difficult to guarantee.

Before the demand is frozen, do not put too much effort into the preparation of the document. The correct way is to keep the appropriate information so that the document can be completed later, not when the requirement is not determined.
Exquisite documents. Formatting a document can easily take a lot of time. If the demand changes, all the investment will be wasted. The input volume of the document should increase as the project progresses. But this is by no means true.
Document is not important, because you must keep enough information to ensure smooth document creation.

Ensure that there are dedicated personnel to accept requests for changes, so that changes in requirements can be controlled. This work can be undertaken by the Project Manager (or similar roles), or by the change Member mentioned below
Will be responsible. Small and fragmented demands can easily affect developers who have more important tasks-to move the project forward. At this time, the project manager is like a buffer zone. It is up to him to determine the classification and optimization of requirements.
Level 1, workload, impact on existing software, and other factors, so as to arrange the plan for demand change-whether completed in this iteration or in the next iteration.

The establishment of a demand change committee is a good practice. It consists of different types of stakeholders of the Project, which may include management, development, customers, documents, quality assurance, and other personnel. They make changes to demand
Evaluate and determine the impact of demand on costs, progress, and various aspects, and determine whether and how to accept the demand. Since the Committee often involves the entire project team, efficiency may become its main
Disadvantage. In this case, the management of the Committee can be strengthened, and the Committee can ensure that the Committee only handles large changes in demand.

Different requirements must be subject to different degrees of constraints in different projects, which sounds a little different from the changes we advocate. Actually not. The main purpose of imposing requirements is to prevent the expansion and
Spread to avoid impractical function lists. We can often mention
"This feature is cool, and our software should include it" and "our competitors have developed this feature, and the final software must include this feature" and so on. This is the typical spread of demand.
MB. The function progress should be correctly estimated at the beginning of the project, and requirements should be controlled during the middle of the project. In the late stage of the project, new requirements should be eliminated, or even existing requirements should be cut off. Three methods can be used to ensure that the software can be released with guaranteed time and quality.

Stable Architecture

Even if the demand has been successfully frozen, we still face a unstable architecture. This is inevitable, and the degree of instability is inversely proportional to the team's ability and understanding of the target field. Because
The architecture also needs to be improved. In the previous model, we discussed restructuring the architecture. In fact, this is a method to make the architecture stable. Empirical data shows that a series of small changes are easier to implement than a large change.
Easier control. Therefore, the practice of constantly restructuring the architecture in iterations may slow down, but it lays the foundation for the stability of the software architecture. Restructuring focuses on the Way of Thinking of two hats.
When the row function is added, the structure is adjusted in the next time period, and the two time periods are never repeated. The structure improvement is not considered when the function is added, the addition of functions is also not considered when the structure is improved. In the architecture
After such a phase of stabilization, its main responsibilities will also become improvements to the structure. From the perspective of our own experience, this stage is very important, improving the software quality, and deepening the project members to the target field.
Understanding is of great help. At this stage, it is easy to extract a general architecture for software organizations to accumulate knowledge.

In this phase, let experienced architects or seniorProgramPersonnel involved in the development process is a good practice. This approach comes from software reviews. It is helpful for improving the software quality or the quality of project members.

The practice of stable architecture implies the stability of a development method. Programmers often like new technologies and tools. This is understandable. However, it is always risky to adopt new technologies and tools in projects.
Some problems may exist in the tool released by the manufacturer, or the technology does not provide good support for the original version. These will have adverse effects on the project. Therefore, if new technologies and
For new tools, it is necessary to arrange time to familiarize yourself with new things at the beginning of the project. Before the architecture becomes stable, the tool usage and technical methods must have been tested and promoted to all members.
Bi. Otherwise, you must make a balance between the extended time and the abandonment of new things.

Excellent practices to ensure stable architecture

InArticleAt the beginning of the project, it is unrealistic to develop an accurate and detailed architecture design at the initial stage of the project. Therefore, there are many practices in Agile Methods to stabilize the initial architecture design. Real
These practices are not entirely new concepts proposed by agile methods. Agile Methods only organize these excellent practices to ensure stable architecture design. We will discuss these practices in detail below.

Seek stability factors in an unstable environment. What is stable and what is unstable. We recommend that you use business entities (
Entity) method to design the architecture. One of the advantages of this method is that the architecture established by identifying business entities is relatively stable. Because the business entity is a stable element in the unstable business logic
. As you can imagine, the concepts of companies, employees, and departments have not changed much over the past few decades. The same applies to specific services. For example, for the general ledger system
Creden, these concepts have never changed much, and their corresponding behaviors are not much different. However, some business logic is completely the opposite. The business logic of different systems is different, and the business logic of different time points is also possible.
Generate changes. For example, for different manufacturing industries, the logic of cost accounting is mostly different. Even if the industry is the same, the business logic has nothing to do with it. Therefore, stable architecture design should depend on stability.
A good practice for unstable factors is to abstract them, abstract stable things, and encapsulate unstable factors in separate positions, avoid impact on other modules. However
The direct result is the interface programming method mentioned in the next section. For example, for the cost accounting mentioned above, although they are changeable and unstable, they still have something stable, that is, most of them.
Manufacturing Enterprises all need cost accounting. This is very important, so it means that the interface methods are relatively fixed.

Another way to maintain architecture stability is to adhere to the interface-oriented programming design method. We have introduced the interface-Oriented Programming Design Method in the layered mode, encouraging abstract and conceptual thinking. From layered Mode
In the example mentioned in (see interface-Oriented Programming in the lower part of layered mode), we can see that an interface can effectively group class functions, this prevents the client programmer from learning that it is irrelevant to him.
Knowledge. In the design model, the separation of interfaces and implementations is very emphasized. The main manifestation is the same. The customer programmers do not need to know the specific implementation. For them, you only need to know the method released by the interface.
.

On the other hand, the reason for separating interfaces from implementations is that interfaces are a relatively stable part of the requirement, while implementations are associated with specific environments. In Java
Methods published by the collection interface. We can see that at this level, the collection interface only defines some stable methods based on the characteristics of the container. For example, add, delete, and compare
Computation. Therefore, this interface is relatively stable, but the implementation details of these methods vary for specific implementation classes. For example, for a list and an array
The added and deleted implementations are different. However, for client programmers, unless they need to understand the underlying implementation, they do not need to understand the add method of list and the add method of array.
Is it different. On the other hand, implementing these methods as fixed and common interfaces is also conducive to interface developers. They can separate implementations from interfaces. In addition, as long as these published interfaces are met
The development team can also develop shared applications. In the current environment, which emphasizes cooperation and efficiency. This development method is very important.

Java. util Interface collection
Boolean	Add ( Objecto)
Boolean	Addall ( Collectionc)
Void	Clear ()
Boolean	Contains ( Objecto)
Boolean	Containsall ( Collectionc)
Boolean	Equals ( Objecto)
Int	Hashcode ()
Boolean	Isempty ()
Iterator	Iterator ()
Boolean	Remove ( Objecto)
Boolean	Removeall ( Collectionc)
Boolean	Retainall ( Collectionc)
Int	Size ()
Object []	Toarray ()
Object []	Toarray ( Object [] A)

Rebuild. Code refactoring is another way to stabilize the architecture. To be accurate, refactoring should be a kind of personal qualities of programmers. However, in practice, we find that refactoring is more suitable for development.
Team actions. Why? When I first came into contact with the concept of refactoring, I did not have a deep understanding of object-oriented. Therefore, the concept of refactoring is not common. However, with the accumulation of experience, the depth of Object-oriented Thinking
. I gradually found that refactoring is a very good way to improve code. It gradually improves code quality through atomic operations to improve the software architecture. When programmers gradually use refactoring
He no longer sticks to these atomic operations, but naturally writes excellent software. This is an improvement of the Reconstruction Method for individual behavior. On the other hand, for a team, each person's programming level and
Lack of experience, 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 problem is much more difficult than the previous one. This
The time reconstruction method is more powerful. Advocating use and even semi-mandatory use refactoring in the team helps to share excellent software design ideas and improve the overall architecture of the software. At this time, the reconstruction is not limited
Code improvement (Martin
Fowler's various methods mentioned in refactoring also involve the application of analysis modes, design patterns, and excellent practices. At the same time, we should also see that restructuring also requires the cooperation of other excellent practices. For example
Code review and testing are preferred.

Summary

Factors that stabilize the architecture include freezing demand and improving the architecture. Demand freezing is a prerequisite and architecture improvement is an inevitable step. In the Object-Oriented field, we can use some practical skills to maintain
A stable architecture. These practical skills are embodied in the process from Requirement Analysis to coding. There are many associations between the stabilization mode and the code Verification Mode in the next article. We will discuss the details in the next article.