Iteration is a life cycle model of software development. We can get a lot of benefits by applying iterative design in the design.
Context
In the software life cycle, how do we deal with the development of architecture design?
Problem
Architecture Design often occurs when detailed requirements are not completed. Therefore, as the project progresses, the requirements may be refined and may be changed. The original architecture will certainly have shortcomings or errors. So how should we deal with the original design?
We briefly mentioned the difference between "planned design" and "evolutionary design" in simple design patterns. People in the XP community advocate the use of the "evolutionary design" approach. In the eyes of outsiders, it seems that advocates never need the design of the architecture. they adopt the method from the very beginning. Code And then use refactoring to improve the quality of the code and solve the function of low quality caused by undesigned code.
To a certain extent, there is nothing wrong with this point of view. It emphasizes the importance of code to software and uses some techniques (such as refactoring) to solve the problem of lack of design. However, I do not agree with the "evolutionary design" approach. In my opinion, to a certain extent, "planned design" is necessary, at least in China's software industry, "planned design" has not become the main design direction. In the early stage of software design, it is necessary to put effort into architecture design, this architecture is the basis for your subsequent design and coding processes. However, the design improvements we mentioned at the beginning still exist. How can we solve them?
In the simple design model, we mentioned the necessity of design improvement. However, if there is no way to control the design improvement, the design improvement itself is a nightmare. Therefore, when to improve, how to improve, and how to control are all problems we need to face.
Solution
To achieve continuous improvement, we will introduce the concept of iteration in the development process. The concept of iteration is in my other article Article -- As mentioned in demand practice, we assume that the reader has a basic concept of iteration.
The work before software coding can be roughly divided into the following workflow:
The process in implies a process of information loss. After the user's requirements are sorted out, the developer will remove some information from it. The same thing occurs in the subsequent process, and the information is lost or deformed constantly. What is the problem here? It should be said that the distortion of demand information is very common. What we lack is an effective way to suppress the distortion. In other words, there is a lack of feedback.
If we put our eyes on it, we certainly cannot go straight. When we walk, we constantly adjust our own direction for our goals. Similarly, if there is no feedback mechanism to adjust the direction of a long software development process, the final software is hard to imagine. So we introduced the iteration cycle.
Initial Design and iterative design
In the Team design, we have been emphasizing that the Design Group's initial design must be an original architecture, and then spread the original architecture to every developer, to form a shared vision in the development team. Vision: it is derived from management and represents the aspirations and visions of the future. Here we use it to show what the software looks like in the minds of developers. In the subsequent articles, we will have a chapter devoted to the architecture vision .)
The idea of iterative design, or our incremental design, is similar to the evolutionary design advocated by XP. We can compare and understand the subtlety of iterative design from methods such as XP, crystal, RUP, and clearroom: each iteration is based on the previous iteration, iteration will focus on Reusing, modifying, and enhancing the current architecture to make the architecture stronger and stronger. At the end of the software life cycle, we had a very stable architecture in addition to software. For a software organization, this architecture is likely to be the input or reference of the next software.
We can regard the early Original architecture as the early investment before the first iteration, or we can regard it as the focus of the first iteration. It doesn't matter. The key is that the original architecture is very important for subsequent architecture design. We have discussed that the architecture comes from requirements, but the original architecture should come from those relatively stable requirements.
Tip: In reality, iterative design degrades to "code and fix". (For "code and fix", see simple design ). On the surface, there is no big difference between the two methods, both of which are aimed at improving the original design. However, the difference between the two effects is obvious: "code and fix" is chaotic and has no sense of direction, each improvement only adds a block to a previously leaked block. Every improvement in iterative design is moving toward a stable goal. It brings confidence to developers rather than a blow. In terms of process, we say that iterative design is under control.
From our practical experience, we have found that it is one of the main reasons that this problem has been solved. Therefore, every iteration should be taken strictly to ensure that the plan has been completed, the quality of the software is ensured, and the user needs are met. This is the path to orthodox iteration. |
|
Single Iteration
We say that each iteration is actually a complete small process. That is to say, it also needs to go through these process patterns discussed in the article. However, these models do not work much. You can even finish everything in a short time. Therefore, we seem to have returned to the beginning of the article and re-discussed the architecture design process.
The most exciting thing about a single iteration is that we can always get a fairly stable result in the current iteration. Unlike the general architecture design, we are afraid that the architecture will be faulty, however, you have to rely on this architecture. From our psychological analysis, we are in a continuous construction architecture, and we do not need to avoid changes in requirements, because we believe that in the iteration of the corresponding requirements, we will continue to improve the architecture. Don't think this kind of psychological change is irrelevant. I didn't realize it at first, however, I soon discovered that the new architecture design process is still shrouded in the original fear of changes, and iterative design can easily degrade to "code and fix. The main reason why developers cannot accept new methods is psychological. Therefore, I have to spend a lot of time communicating with developers. This is my practical experience.
Iteration staggered
Based on our experience in operations research, iterative design is certainly not a linear relationship. One reason is that the time difference between the architecture design and subsequent work is still the same. Therefore, we are not stupid enough to waste time waiting for other jobs. Generally, after the current iteration requirement starts, we can start the architecture design of the next iteration before the detailed requirement starts.
The time distance between iterations depends on the specific conditions of the project. For example, in a project with relatively tight personnel, major architecture designers may also need to take the role of coding personnel, the architecture design of the next iteration may have to wait until the coding peak expires. However, multiple staggered iterations may cause version issues. For example, an architecture problem is found in the Code of this iteration and fed back to the architecture design group, however, the architecture design group has started the architecture design of the next iteration Based on the pseudo-modified architecture. At this time, there will be conflicts between different designs. This situation can certainly be solved by strengthening the management of the design model and introducing the version control mechanism, but it will certainly bring about an increasing management cost, which is not in line with agile thinking. At this time, the team design reflects his power, which is also a reason we did not mention in the team design. The team design can solve conflicts in the architecture design through full communication.
Iteration frequency
XP advocates that the shorter the iteration cycle, the better (XP recommends one to two weeks). This is a good proposal. In such a short iteration cycle, we may spend only one or two hours to half a day on architecture design. At this time, there will be a very interesting phenomenon, it is difficult for you to distinguish between architecture design and design concepts. Because within such a short period of time, there are few requirements to complete, and there may be only one or two use cases or user materials. Therefore, is the design of these requirements an architectural design? If so, since the development process is composed of multiple iterations, isn't the design in the development process an architectural design? We say that architecture is a relative concept and is specific to the scope. In the traditional waterfall model, we can easily distinguish between architecture design and general design, if we think of an iteration as a separate life cycle, there is no difference between a common design and an architecture design. However, the architectural design in the iteration cycle must follow certain principles, which we will mention below.
We hope that the faster the iteration frequency, the better, but it depends on the actual situation. For example, in the initial stage of a data warehouse project, we had to spend a lot of time on data modeling. This is actually a data-specific architecture design and metadata creation, this process is hard to be divided into multiple iteration cycles.
How to determine the software iteration cycle
It can be said that if a development team does not have the concept of iteration, it is very difficult and meaningless for this team to implement the iteration cycle immediately after two weeks. As we have discussed above, there are many factors that affect the iteration cycle, so that we cannot quantify the definition of the iteration cycle. Therefore, we can only analyze the development of iteration cycles from a qualitative perspective.
Another method to understand iteration is to read related information about xp. I think the use of iteration cycles in XP is a good method, but he stressed that such a short iteration cycle is hard for many software teams to achieve.
The introduction of iteration cycles must be a process from rough to accurate. The essence of iteration is actually a short-cycle plan, so this is also a major reason for the benefits of the shorter iteration cycle, because the shorter the time, the more predictable the plan. We know that planning is based on past experience. If we didn't have the experience of planning or planning details, our plan must be very rough, the final error must also be large. But it does not matter. Every plan will have a positive impact on the next plan. When the experience is sufficient, the plan will be very accurate, and the final error will be very small.
The determination of the iteration cycle depends on the unit of work. Unit workload refers to the minimum performance you can quantify within a certain period of time. The simplest unit workload is Program Number of encoding lines per day. Unfortunately, it is often cruel to show that the Team has not only the roles of programmers, but also designers, testers, document producers and other roles, the number of lines simply encoded cannot be used as the only statistical basis. Similarly, emphasizing only the number of encoding lines also causes other problems, such as code quality. To ensure the rationality of statistics, a good practice is to set the number of days a team spends on a function as a unit of work. The content discussed here is actually the software measurement technology. If you have the opportunity, I will discuss this issue with you.
Iteration cycle and software architecture Improvement
The biggest purpose of our application iteration method is to steadily improve the software architecture. Therefore, we need to understand how the architecture evolves continuously in the software development process. In the subsequent articles, we will talk about using refactoring to improve the software architecture. However, the definition of refactoring emphasizes that refactoring must be implemented without modifying the Code's external functions. For the architecture, we can almost equivalent that it is to improve the architecture without changing the external interfaces. In actual development, it is very difficult to keep all the software interfaces unchanged throughout the software development process unless you are very experienced. Therefore, although the architecture improvement mentioned here is similar to refactoring, there are still differences.
The improvement of the software architecture will go through a critical period in the software development process, which may span several iteration cycles, during which the architecture design will undergo drastic changes, but in the end, it will certainly be stable. (If there is no stable design at the end of the project, it is unfortunate that your project is doomed to fail, either due to time or demand issues ). The key issue is whether we have the courage to make changes when the architecture needs to be changed, rather than watching the problem become more and more serious. In the final example, we discuss three iteration cycles. If we refuse to change the architecture in the second cycle, the third cycle must be like a nightmare. Change to make it possible to succeed.
We know the importance of changes, but there is no way to know the exact time of changes. However, we can smell the changing architecture from the development process: When repeated code in the Program increases, when some classes become exceptionally bloated, when the encoding speed of the encoding staff begins to decrease, the demand changes a lot.
Example:
From this week, my team and I will be responsible for the design of the presentation layer in the software project. In this iteration cycle, our task is to provide 6 to 10 views for the client. Because there are not many views, the architecture design of the presentation layer is very simple:
To be precise, we cannot talk about the design here, but simply let the client access different views. Of course, in the design, we do not need to draw all views, as long as we can express the relevance between the client and the view.
(The architecture design needs to be bound with the specific implementation, but in this example, unnecessary information is deleted to emphasize the evolution of the design. In actual design, a view may be a JSP page or a window .)
The task of the first iteration week was quickly completed, and the presentation layer module in charge of the group was also smoothly connected with other groups. A simple but operational small system was successfully released. The customer watched the demonstration of the system and made modifications and supplements to the system.
In the second iteration Week, the number of views to be processed by the module has increased to 30, and the views have the same part. In addition, the data layer team told us that due to the improvement of customer requirements, different data sources will appear in the same view. Because our views directly use the functions provided by the data layer group to our data sources, this means that our design needs to be adjusted significantly.
Considering the large increase in the number of views in the system, it is necessary to manage the views in a centralized manner. Front-end controller (Front control) mode will be a good trick. For the common duplicates between views, you can divide the views into different subviews, and then combine the subviews into various views. In this way, we can use the composite mode:
The customer's requests are submitted to the Controller in a centralized manner. After the Controller receives the customer's requests, it provides different views to the customer according to certain rules. The controller is a scalable design. Currently, there are not many views, so you can still use the Controller to directly allocate views. If the view processing rules are complex, we can also use the create factory mode to specifically handle the view generation problem. For views, the combination mode is used to combine views of multiple different data sources into complex views. For example, a JSP page may need to be divided into the header page and the end page.
After the project enters the third iteration cycle, the requirements of the presentation layer are further complicated. We need to process the permission information, determine the legitimacy of the data to be processed, and face the increasing complexity caused by more views.
The permission processing in the presentation layer is relatively simple. We can add a permission control module from the front-end controller. In addition, to solve the legality judgment problem, we have added a data filter chain module to complete data legality judgment and conversion. In order not to make the functions of the controller too complex, we transfer the view Distribution Function originally belonging to the Controller to the new distributor module, and the Controller is responsible for the control of user requests and views.
Let's review this example. The requirements in iteration cycle 1 are the simplest. In fact, although the requirements of the current project may not be as simple as those in the example, they will not be too complex, therefore, the design of iteration cycle 1 is also very simple. By the time of iteration cycle 2, the requirements began to become complex. Continuing to design based on the original architecture will inevitably lead to many problems. Therefore, it is necessary to improve the architecture. We can see that the new design can meet new requirements. Similarly, the demand for iteration cycle 3 is more complex, so the design also evolves. This is the idea of "evolutionary design" that we mentioned at the beginning of this 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 via email iamlinx@21cn.com
