Live XP: (3) practice iteration
Lin Xing (reprinted from www-900.ibm.com) October 27, 2003
After understanding the basic ideas of the phased development software, it is necessary to consider the implementation of the implementation. The most difficult in phases is not on the control of the process, but on software design capabilities. There is a story about iterative problems. It is said that a person is hurt, go to see a doctor, the doctor gives him an eye medicine, the reason is that the eyes are not good, it is wrong, so I will have a stomach. The problems that occur in software development are often not a simple problem, headache medical head, and the practice of foot pain may not be suitable for software development.
Application iteration is not a simple thing, knowing the concept of iteration and increment, is not equal to you can use them. Why do you say this? Many software organizations tried to use iterative development, but the result is not satisfactory, so it is unrealtierable. There is a famous word in the software engineering? Quot; no silver bomb ". Iterations and increments are not a silver bomb. To do it, lack excellent software design ideas and high software designers' support is not. In XP, it is very emphasized that all practices are complementary. In my opinion, iterative can successfully implement the direct support for reimbursement, test priority, continuous integration. And these practices reflect the software design and software Relationship.
Iterative practice has problems often in the mid-term of the project. At this time, the main body of the software has been formed, and the growth rate of the code is also in a rapid growth. Software development in this state is the most resistance, especially those that have problems in the design itself. Software is developed to this stage, and the code is often more chaotic, lacks a main line or the foundation architecture. At this time, the changes in demand, or the cost of the new demand rises, and the project progress has become difficult to expect, and the developer's morale is affected.
Solution other than iterations At this time, software organizations should do, not on the issue of iteration, but should start from software design, find a software design idea or method that adapts to changes. For example, should you consider doing some research in the object-oriented field? Object-oriented ideas focus on distinguishing between changes and unchanged content to support future changes and uncertainty. Then you will take into account the corresponding cost.
There are several things worthy of iteration:
The ability of code design optimization software development is not reflected in the amount of code, but reflects the function of code implementation, scalability, understandability. Therefore, the code is continuously improved, and the design is continuously improved (depending on the number of times as needed), so that the structure of the software is relatively stable, and can be supported. This is a prerequisite for iteration. Otherwise, each iteration spends a lot of energy to modify the original design, optimize the code, so iterative efficiency is not high, or it can be considered a waste. Adhere to continuous improvement of software quality is actually sharing the centralized maintenance of software to the entire process, this idea, and the idea of comprehensive quality management is very similar. Reconstruction practices in XP have a modified word called ruthless. This fully demonstrates XP's heterogens, but it should be recognized that only the quality of design and code can make a foundation for subsequent iterative processes, not to mention, XP is often an uncertain, changing multiple environments . It is precisely because this environment has a great impact on software development, so code quality is also highly valued. Different industries, different projects, need to be adjusted according to their own characteristics, but only guarantee the grace of code, it can achieve iteration goals smoothly.
Code design optimization must maintain a simple principle and do not perform a lot of design input at the beginning. I have convinced that the software coding, strict software design is indispensable. But slowly, I found this idea that this idea is not necessarily correct. After summed up some experience, I found that many time is actually wasted in design. In a software design, there is a strong requirement for the interface structure, and Eclipse's design ideas are justified. Therefore, I excitedly injecting Eclipse's design ideas into interface design, after spending a lot of time for design and implementation, found that it does not meet the needs. More bad, due to the complexity of design, the difficulty of debugging and changing is increased, and other members of the team also means that this idea is difficult to understand. The final design was abandoned, but the loss was already caused, complex design and implementation, enough to spend a week of development time.
Reconstruction and review In addition to the first iteration, the subsequent iterative process is based on the previous iteration. Therefore, the problems accumulated in each iteration will eventually react during subsequent iterations. To ensure that iterates smoothly, reconstruct and review the code is less work. The most important work is to eliminate duplicate code, and the duplication of the code is the culprit of the code messy. Elimination of duplicate code is not only to find a letter, it involves reconstruction, object-oriented design, design patterns, frameworks and many other knowledge. The introduction of these knowledge is not the focus of this article, but we must know that only strict control quality, the quality of the software and the quality of the software process are guaranteed.
Postpone Design Decision Lean Programming Tell us to delay decision-making as much as possible. In a changing environment, early decisions often lack sufficient factual support and practice proven. Even if it is a higher software designer, it will inevitably make mistakes. This is very normal, then since the current decision is very risky, why should we still have to make a decision? On the issue of designing this, a better approach is to avoid high-difficult, high waste design to meet existing needs as the achievement. Future demand waits to adjust when it is determined.
Postponed decisions is actually a major capacity for software design. Why do we recommend using object-oriented technology? Because object-oriented technology has strong ability to postpone decision making, first incorporated the currently identified problem into object-oriented design, and leaving expansion for future uncertainty. Postponed decisions are not a simple problem, it requires a strong object-oriented design thinking.
There are many examples in the design model, with a strong representation of the decorative model.
When the design is just beginning, no one knows what the last development of ConcreteComponent is like. Obviously, this is a design in an uncertain environment. We can determine, only the Component system will have Operate, so we designed an interface component to constrain the system, require all subclasses. Have an Operate method. Another purpose is to provide a unified interface for client calls, so that the client has learned the minimum level to the server information, just know how the OPERATE method, and select the appropriate class. Further improvements can also be further improved, and the degree of coupling is further reduced.
After unify the interface, we can implement existing features as needed, we implemented a ConcreteComponent class that implements the Component interface and implements the core function. If in the future, the demand changes, we will add additional behavior, we use the ConcreteDecorator class to add new features for ConcreteComponent: public class concretecorator import; public void Operate () {// extra behavior component Component }}}
First find a common point, then implement common point, and design uncertain information as an extension, this is the design idea of postponed decision-making. However, it should be noted that the design of the above example still has many restrictions, for example, the increased demand (that is, a constradedecorator) may have a new interface, for example, a Anotheroperate method, this time, the original extension Sexual design has become difficult to meet the needs. In software design, although the flexibility and scalability for interface design is much more than previously designed, it is not universal, and depends on the designer's understanding and design level of demand. In addition, the delay design decision requires us to learn abstract thinking, identify, and distinguish between changes and constant parts.
Focus on the interface instead of paying attention to implementing Martin Fowler divides software design into three levels: concept (Specification) Level, Implementation level. Software design should stand as much as possible in the concept, instead of excessive attention. Sometimes we find that the software is difficult to withstand this change during iteration, then a large problem may be a problem with the protocol and achievement. When we discussed reconstruction and review in front of the previous section, we said that the elimination of duplication is a complex work. It is the most effective way for the statute design, but it is also the hardest method.
We can imagine the statute to imagine the interface or an abstract class, or the specific class's public method, and imagine the implementation level as the implementation class, implement details. Then, our principles should design a stable stability level as possible, and provide a good, simple interface (interface) for our customers (probably a real customer, most of which use your code customer programmer). Society has developed to the current level, and anyone will take too much time to study your code. If your code can provide convenience for others, then the last phase-out is your code. The success of the Java language is largely that he has provided a simple, easy-to-use, and clear status interface while ensuring powerful features.
In software design, it is very common to pay attention to the design of the statute. Why do we advocate software design for three-story architecture? The most important thing is because he has reasonably contributed rationality for the software structure, far exceeding his other value. In modern software design, databases, interfaces, business modeling is actually three differences in three differences, which leads to different changes in three. According to the principle of distinguishing between different changes, we know that three technologies must be distinguished. And this is the main idea of the three-layer architecture. From this idea, we can also evolve the three-layer architecture into a four-layer architecture, even multi-layer architecture according to the needs of the change. Between multiple levels, it is the most loose coupling through excellent stations.
In lean programming, in order to avoid waste, it is necessary to require the stability of each programmer to improve the stability of the code. In a system, the design excellent status interface can have a relatively good resistance to adapt the iterative process. The software registered 2 has a behavior that does not exist in version 1, called return. Regression is the main problem in software development. The original behavior is affected while modifying existing functions, which is the main reason for bugs. In the process of iteration, the emergence of regression behavior must be avoided. The main solution to avoid regression is to build automation tests to achieve regression test.
The key to successfully constructing the regression test is still available to design an excellent statute interface and test it for the statute interface. In this way, it is not only designed to have anti-varyingness, but the test also has resistance to resistance. The only thing that may change is only realized. With the help of the regression test, the change in code is not surprised. We put a detailed discussion of the test in the test section.
Organizational rules In subsequent chapters, we will discuss a very characteristic organizational rules in XP - pair programming. Here we need to know that different teams have different organizations, and its iterative process also needs to apply different organizational rules. For example, the size of the organization, small-scale organizations can apply faster iterative cycles, such as one week, in an iterative cycle, teams can focus on developing a requirement, emphasizing reconstruction and testing, avoiding too much pre-design. For large organizations, it can consider a longer iterative cycle, more focused on the previous design, and interleave with the iterative cycle of developers and testers. The organization of the team is also the main reason for the impact of the iterative process. Whether the team is constructed by the same level, whether the expertise of each person can complement each other, and the team has a communication problem.
