Six, iterative design
Iteration is a lifecycle model for software development, and we can get a lot of benefits in design.
Context
In the software life cycle, how do we treat the development of architecture design?
Problem
Architecture design tends to occur when the details are not completed. Therefore, as the project progresses, demand can be refined and possible to change. The original architecture will definitely have indifferent or wrong places. So, how should we treat the original design?
We simply mention the difference between "Planned Design" and "Evolutionary Design" in simple design patterns. People in the XP community advocate the way "Evolutionary Design", in the view, it seems that the guards never need the architecture design, the way they use is the writing of the code, then use refactoring to improve the quality of the code. To solve the function of low code quality that is not designed.
To a certain extent, this view is not wrong. It emphasizes the importance of the code to the software and solves the lack of design issues by some techniques (such as refactoring). But I don't agree with the way "Evolutionary Design". In my opinion, "Planned Design" must be, at least in China's software industry, "Planned Design" has not become the main design direction. Borrowing a saying, "Everything is required to be inexpensive", in the early stage of software design, the design of the architecture of investment is very necessary, this architecture is the basis for the dependence on the decision during the coding process. However, when we mentioned the design improvement problem, how do we solve it?
In a simple design pattern, we mentioned the need to design improvement, but if there is no way to control the improvement of the design, then the design improvement itself is a nightmare. Therefore, when to improve, how to improve, how to control, this is what we need to face.
Solution
In order to achieve constant improvements, we will introduce iterations in the development process. The concept of iteration has been mentioned in my other article - "Demand Practice", here we assume that the reader has a basic iteration concept.
The work before software coding is roughly divided into such a workflow:
The flow in the above figure implies a process of loss of information. After the requirements of users have been organized, the developers will remove some information, and the same thing happens in the following procedure, and the situation of information loss or deformation occurs. What happened here? It should be said that the distortion of demand information is very common. We lack a valid approach to suppress distortion, in other words, it is lacking feedback.
If you blind your eyes, we must have no way to get a long straight line. When we walk, we are constantly adjusting your own direction. Similarly, the long software development process If there is no feedback mechanism to adjust the direction, the last software is really unimaginable.
So we introduced iterative cycles.
Initial design and iterative design
In the team design, we have been emphasizing that the design group started design must be just an original architecture, then spreading this original architecture to every developer's hand, thus forming a common vision in the development team. (Vision): From management, expressing future wishes and sights. Borrow here to express the software in the heart of the developer. In the later article, we will have a chapter special discussion architecture vision.) Iteration ( Iterate, or we call the idea of incremental design and XP advocated Evolutionary Design has the wonderful work. We can learn from XP, Crystal, Rup, Clearroom, etc. The architecture so that the architecture is getting stronger and strong. In the end of the software life cycle, in addition to getting the software, we also got a very stable architecture. For a software organization, this architecture is likely to be in the next software input or reference.
We can use the early original architecture as the early investment before the first iteration, or it can do it as the first iteration, it doesn't matter. The key is that the original architecture is very important for subsequent architecture designs, we discuss architectures from demand, but the original architecture should come from those relatively stable needs.
TIP: Reality orthopedic design Degradation is designed to "Code and Fix". See Simple Design of "Code and Fix". From the surface, the approach of the two is not too big, which is improving for the original design. However, the difference in the effects is obvious: "Code and fix" is chaotic, there is no direction, and each improvement is just a block of building blocks that have been shaken in the building blocks. Every improvement in iterative design is moving toward a stable goal, and he brings confidence to the developers instead of blow. In the process, we said iterative design is under control.
From the experience of practice, we found that it is one of the main reasons for this problem with the problem that the problem is currently resolved. Therefore, please strictly treat each iteration to ensure that the plan has been completed, ensuring the quality of the software, ensuring that the user's demand is satisfied, so it is an orthodox iteration.
Single iteration
We said that every iteration is actually a complete small process. That is to say, it also has to experience these process patterns discussed in the article. However, these patterns have little work, you can even do everything in a short time. Therefore, we seem to return to the beginning of the article, re-discuss the process of architecture design.
The single iteration is the most exciting thing that we can always get quite stable in the current iteration, rather than the ordinary architecture design, we deeply scramble the architecture, but have to rely on this architecture. From our psychological analysis, we are in a continuous construction structure, we do not need to avoid changes in demand, because we believe that in the iterations corresponding to the needs, we will continue to improve the architecture. Don't think that this kind of psychological changes are irrelevant. I didn't realize this issue, but I quickly found that the new architecture design process still shrouded under the shadow of the original fear change, it is easy. The situation degraded into "Code and fix". The main reason for developers is difficult to accept new methods or psychologically. Therefore, I have to spend a lot of time to communicate with developers, this is my real experience.
Iterative interlaced
Based on our experience in the training, iterative design is definitely not linear relationship. One cause of architecture and subsequent works are still poor. Therefore, we will not be stupid to waste time in other work. In general, after the next iteration is started, we can start the next iteration architecture before the desire requires. The time distance between each iterative is dependent on the specific situation of the project. For example, in a tense project, the main architectural designers may also serve as the role of the coding personnel. The next iterative architecture design may wait until the peak period of encoding work is over. However, multiple interlaced iterations may generate a version problem. For example, a problem with the architecture is found in this iterative encoding, which feeds back to the architecture design group, but the architecture design group has started the next iterative architecture design based on the pseudo-modified architecture, this will appear at this time. Conflict between different designs. This situation can of course be solved by strengthening the management and introduction of the design model, but will definitely bring the problem of management costs, and this is not in line with agile ideology. At this time, team design reflects his power, this is also a reason why we have not mentioned in team design. The team design can solve the problem of conflict in architectural design through full communication.
Iterative frequency
XP advocates that the shorter the iterative cycle is, the better (XP is recommended for one to two weeks), this is a good proposal. In such a short iterative period, we spend the time of architecture design may only have one or two hours to half a day. At this time, there will be a very interesting phenomenon that you'll be difficult to distinguish between architecture design and design. Because in such a short cycle, the number of demand completed is very small, and there may be only one or two cases or user materials. Therefore, is the design of these demand belong to architecture design? If so, because the development process consists of multiple iterations, is the design of the development process not belong to the architecture design? We said that the architecture is a relative concept. In terms of the scope, in the traditional waterfall model, we can easily distinguish between architecture design and ordinary design. If we regard iteration as a separate life cycle Then, ordinary design is within such a range, which is architectural design, and they don't have anything. However, architectural design in iterative cycles is to follow certain principles, which will be mentioned below.
We want the iterative frequency, the better, but this will also be determined according to the reality. For example, in the initial stage of the project, we have to spend a lot of time for data modeling, which is also a structured architecture design, establishing metadata, setting dimension, finishing data, such a The process is difficult to divide into multiple iterative cycles.
How to determine the iterative cycle of the software
It can be said that if a development team does not have the concept of iterative, then this team should immediately achieve it very difficult for the two-week iterative cycle, and it is also meaningless. As we discussed above, there are many factors affecting iterative cycles, so that we cannot quantify the iterative cycle. Therefore, we can only analyze the development of iterative cycles from qualitative perspective.
Another method of understanding iteration is to read XP-related materials. I think that the use of iterative cycles is a very good way to use the iterative cycle, but he emphasizes that such short iterative cycles are difficult to implement for many software teams. of.
The introduction of iterative cycles must be a process from rough to accurate. The essence of iteration is actually a short period of plan, so this is also a big reason for the iterative cycle, the more beneficial to us, because the time is shortened, the planned predictability is enhanced. We know that the development of the plan is dependent on the experience. If we have not developed the experience of the plan or detail plan, then our plan must be very rough, and the final error must be great. But this doesn't matter. Every plan will have a positive impact on the next plan. When the experience is enough, the plan will be very accurate, and the final error will be small. The determination of the iterative cycle needs to be dependent on the unit workload. The unit workload refers to the smallest performance you can quantify for a certain period of time. The easiest unit workload is the number of codes per program a day. Unfortunately, it is often more cruel. There are not only programmers, but also the existence of designers, testers, document producers, etc., the number of simple coding lines cannot be used as a unique statistical basis. Similarly, only emphasis on the number of rows, can also cause other problems, such as code quality. In order to ensure the rationality of statistics, a better approach is a team to achieve a certain number of days as a unit workload. The content discussed here is actually software measurement technology. If there is a chance, then discuss this issue.
Improvement of iterative cycle and software architecture
The biggest purpose of our application iterative method is to steadily improve the software architecture. Therefore, we need to understand how the architecture has evolved in the process of software development. In the following article, we talk about the method of refactoring to improve the software architecture, but the defactoring is emphasized in the definition of the refactoring, and the refactoring must be performed without modifying the external function of the code. For architectures, we can think of an almost equivalent to improve the architecture in the case of an external interface. In actual development, unless it is very experienced, it is a very difficult thing to maintain all software interfaces in the whole process of software development. Therefore, the improvement of the architecture we talk about here is similar to the refactoring, but it still has different differences.
The improvement of the software architecture experiences a oscillation period in the software development process. This oscillation period may span several iterative cycles, and the design of its architecture will experience dramatic changes, but finally will be stable. (If there is no design stability in the later period of the project, then very unfortunate, your project is destined to fail, or the problem is a problem, or it is a problem of demand). The key question is that we have no courage, and make changes in the architecture to change, not the problem of watching the problem is getting more serious. In the final example, we discuss three iterative cycles, suppose we refuse to change the architecture during the second cycle, then the third cycle must have a nightmare. Change can be successful.
We know the importance of change, but there is no way to know the exact time of the change. However, we can smell the odor from the development process: When the duplicated code in the program gradually changes, when some classes become extra bloated, when the coding person's coding speed begins to fall, When the demand has a lot of change.
example:
From this week, I and my group will be responsible for the design of the representation of the software project. In this iterative cycle, our task is to provide 6 to 10 views for the client. Since the view is not much, the architecture of the representation is very simple:
Accurately, talking here is not designed, just simply letting client access different views. Of course, in the schematic diagram of the design, we don't have to draw all the views, as long as the association of the client and the view can be expressed.
(Architecture design needs and specific implementation binding, but in this example, in order to focus on the evolution of the design, unnecessary information is deleted. In the actual design, the view may be a JSP page, or one may be one Window.) The task of the first iterative week is complete, and the group responsible for the group is also a smooth and other groups complete the docking, a simple but able to operate smoothly. The customer watched this system's demo and made a modification and supplement on the system.
In the second iterative week, the view to which the module to be processed has increased to 30, and there is the same part between the view, and the group responsible for the data layer says that due to the improvement of customer needs, it will appear in the same view. Data source. Since our view directly uses a function of the data source provided to our data source, this means that our design needs to make greater adjustments.
Considering the amount of the system's view, we need to centrally manage the view. The Front Control mode will be a good tip. For a universal repeating part between the view, the view can be divided into different subviews, and then combine the child view into a variety of views. This way we can use the Composite mode:
The customer's request is submitted to the controller. After the controller accepts the customer's request, different views are provided to feedback to the customer according to certain rules. The controller is an expanded ability design, and there is not much view of the current view, so the controller can still be used directly to allocate the view. If the processing rules of the view are more complicated, we can also use the Create Factory mode to deal with the problem of generating views. For view, use a combination mode to combine the views of multiple different data sources into complex views. For example, in a JSP page, you may need to be divided into a header and tail.
After the project enters the third iterative period, the demand of the layer is further complicated. We need to process permission information, and we need to process the legality judgment of data, and we need to face more complicated proven to be brought about by more views.
The privilege of the layer is relatively simple, and we can add permission control from the front controller. At the same time, in order to solve the problem of legality judgment, we have added a data filter chain module to complete the legality judgment and conversion of the data. In order not to make the function of the controller part of the controller, we transfer the view distribution functionality of the controller to the new distributor module, and the controller is responsible for the user request, the view control.
Let's review this example, from the requirements of the iterative period, it is simpler, in fact, the demand in the reality is not necessarily simple in the example, but it will not be too complicated, so the iterative period 1 is also Very simple. When the iterative cycle 2, the demand begins to become complex. If the original architecture continues, it will inevitably lead to a lot of problems, so it is necessary to improve the architecture. We see that new design meets new needs. Similarly, iterative cycle 3 is more complicated, so the design also evolves. This is the idea of the evolution of "Evolutionary Design" in the beginning of the article.
