The rise of Agile Methods puts forward new requirements for design. The core of agile methods is the design of progressive Design for demands that cannot be fixed from the very beginning of the project. 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 delivered in a stable form of code. 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 that all the preliminary work has been completed before coding and testing are started. If the demand changes, strict control is required. In reality, this method is often due to the inconsistent understanding of the needs of both developers and customers, and the change of the needs itself, resulting in the project to completely solidify the demand in the early stage becomes unrealistic. The result is either that the customer's interests are damaged by rejecting the change in demand, or that the project is out of control due to the change in demand. 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 easy to grasp the requirements, 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, when iterative development enters a certain stage, we need to freeze the demand. At this time, the demand freezing is different from the above mentioned requirement fixing at the beginning. First of all, after one or several iterations, the user has an image of software development, and the demand 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, users' 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 time point is often in the middle of the project. If the demand remains unstable at this time, it is difficult to guarantee the final success of the project.
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, the format of the document is not required when the requirement is not determined. 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. However, this is by no means not important to documents, because you must keep enough information to ensure smooth creation of documents.
Ensure that there are dedicated personnel to accept requests for changes, so that changes in requirements can be controlled. The Project Manager (or similar roles) can be responsible for this work, or the Change Committee described below. 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, which determines the requirement classification, priority, workload, impact on existing software, and other factors, so as to arrange the demand change plan-whether it is 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 assess and decide on demand changes, assess 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 constraints on requirements is to prevent the expansion and spread of requirements and avoid impractical function lists. We can often mention something like "This feature is cool, our software should include it" and "our competitors have developed this feature, the final software must include such a function. This is a typical indication of the spread of demand. 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. Therefore, 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 and control than a large change. 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 the two hats, that is, the function is increased in this period of time, and the structure is adjusted in the next period of time. The two periods are never repeated, the structure improvement is not taken into account when adding functions, and the addition of functions is also not considered when improving the structure. However, after the architecture is stabilized, its main responsibilities will also become improvements to the structure. From the perspective of our own experience, this stage is very important. It is of great help to improve the software quality and deepen the understanding of the project members in the target field. At this stage, it is easy to extract a general architecture for software organizations to accumulate knowledge.
In this phase, it is a good practice to involve experienced architects or senior programmers in the development process. 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 tools must be used in the project, it is necessary to arrange time for new things to become familiar 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. Otherwise, you must make a balance between the extended time and the abandonment of new things.
Excellent practices to ensure stable architecture
At the beginning of the article, we will talk about the fact that it is unrealistic to develop an accurate and detailed architecture design in the initial stage of the project. Therefore, there are many practices in Agile Methods to stabilize the initial architecture design. In fact, 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 the Business Entity Method for architecture design. 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, the concepts of subjects, balances, sub-accounts, and original creden 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 may change at different time points. 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 rely on a stable foundation. For unstable factors, it is better to abstract them and abstract stable things, the unstable factors are encapsulated in separate positions to avoid the impact on other modules. The direct result of this idea 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 manufacturing enterprises 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 the examples mentioned in the layered mode (see the interface-oriented programming section under the layered mode), we can see that an interface can effectively group class functions, this prevents the client programmer from learning anything unrelated to him. 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. Methods published for the Collection interface in Java. 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 operations. 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, they are different for addition and deletion. However, for client programmers, unless they need to understand the underlying implementation, they do not need to understand the differences between the add method of List and the add method of Array. 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, other software development teams can also develop applications that can be used together. In the current environment, which emphasizes cooperation and efficiency. This development method is very important.
Java. util
Interface Collection |
| Boolean |
Add (Object o) |
| Boolean |
AddAll (Collection c) |
| Void |
Clear () |
| Boolean |
Contains (Object o) |
| Boolean |
ContainsAll (Collection c) |
| Boolean |
Equals (Object o) |
| Int |
HashCode () |
| Boolean |
IsEmpty () |
| Iterator |
Iterator () |
| Boolean |
Remove (Object o) |
| Boolean |
RemoveAll (Collection c) |
| Boolean |
RetainAll (Collection c) |
| Int |
Size () |
| Object [] |
ToArray () |
| Object [] |
ToArray (Object []) |
Reconstruction
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 the common behavior of the development team. 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. But 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 become familiar with refactoring, they no longer stick to these atomic operations, but naturally Write Excellent Software. This is an improvement of the Reconstruction Method for individual behavior. On the other hand, for a team, everyone's programming skills and experience are not enough, 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. At this time, the refactoring method can exert its power. 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, refactoring is not limited to code improvement (referring to various methods mentioned by Martin Fowler in refactoring ), it also involves the application of analysis mode, design mode, and excellent practice. At the same time, we should also see that restructuring also requires the cooperation of other excellent practices. For example, code review and test 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.
(To be continued)
Author profile:
Lin Xing, Senior Project Manager of the Project Management Group of Chen Xun software studio, has many years of project implementation experience. Chen Xun software studio is committed to the application of advanced software ideas and software technology. Its main research direction is software process ideas, Linux cluster technology, OO technology and software factory model. You can contact him by email iamlinx@21cn.com.
