Use XP

Lin Xing, Project Manager Lin Xing, Chen Yun Software Studio Project Management Group Senior Project Manager, has many years of project implementation experience. Chen Xun Software Studio is committed to the application of advanced software ideas, software technology applications, main research directions lies in software process ideas, Linux cluster technology, OO technology and software plant models. You can contact him by email IAMLINX@21cn.com. August 01, 2003

(1) Playing process and people's power

The agile method represented by XP began to be familiar with more and more industry insiders, and many people also expressed interest in agile ideas, but in the process of practice, there is always like this, and the XP can Cannot be used to guide practice, or XP only can only exist in the book? This article will answer this question.

Although software development has multiple links, we cannot only emphasize some links, and any problem will eventually affect the quality of the product. So we should consider the entire process in software development and pay attention to this factor.

Quality inspectors work

In the previous factory workflow, the product needs to be checked by a quality inspector after production. At the quality inspectors, there are two baskets, a basket written, and a basket is unqualified. For qualified products, post the certificate, enter the sales, for unqualified products, prohibiting the factory. For a long time, we have been using a quality inspection in the final stage of the product, which is used to avoid quality defective products, but there is no way to improve the quality of the product, and there is no way to reduce the error rate. The basic idea of ​​this quality inspection method is that the product has a waste product, as long as the waste can be found, the quality of the product is not affected.

Then let's take a look at the process of software development. When the software has experienced demand, analysis, design, and encoding, the quality inspector also needs to verify whether the software meets quality requirements. A variety of testers jointly served as a quality inspector. And the quality inspectors are not simple. Black box test, white box test, integrated test, user test, parallel test. Unlike the factory, problems with problems do not easily throw it into unqualified product stacks. Another difference, software products will have quality problems. Since you can't give up the product, you have to return the product to the production line. Therefore, the demand personnel, analysts, designers, and codents have begun to adjust the software, and try to make the software to factory. This repeated process tends to last for a while. Fortunate software can be transferred to the factory (delivery), otherwise it may be fate from the project failed.

Obviously, we have found that this practice is not smart enough. Stacked the problem until finally settled to solve it, this approach is very high. The characteristics of software development have determined that the more post-changes, the higher the cost. So how should we adjust our approach to reduce costs, improve quality?

Lean principle

Software development always borrows management ideas from other disciplines. The earliest software engineering learns from the civil engineering, but later people find great differences in construction and software development. Therefore, the new software development method began to rise, including XP methodology. Similarly, the new software development method is still in theory to find a foothold, and this focus is in the modern management concept. A large question of civil engineering management is to ignore the role of people, and modern management philosophy refer to a new height, which is the same as emerging software development ideas. The most influence on software development ideas should be considered the concept of Lean Production, which is proposed by Toyota.

The United States after World War II, the car manufacturing company headed by Ford advocated the mass production (Mass Production), and Toyota Ying Second and others were in the United States after investigation, it was not suitable for Japan after investigating the US manufacturing ideas. It is proposed that the idea of ​​Lean Production, lean manufacturing has been a generation of hegemon-Toyota, Toyota's manufacturing method is called TPS (Toyota Production System). Toyota's Toyota Yingqi and Duya-class also conducted a series of exploration and experiments. According to Japan's national conditions, a series of improved production methods: timely production, comprehensive quality management, parallel project, gradually created unique Multi-variety, small batches, high quality, low consumption production methods. After more than 30 years of practice, these methods have formed a complete "Toyota production method" to help the automotive industry's later generations of Japan surpass the automotive power of the United States, and the output reached 13 million, accounting for more than 30% of the total world. Review this history and how similar software development history is. Large-scale manufacturing theory believes that a certain degree of waste is normal, allowed. In software development, waste, cost is also a major obstacle to preventing software development towards engineering. A agile method like XP has learned a lot of excellent ideas from lean manufacturing ideas, for example, continuous improvement of quality, design decisions should be handed over to the closest-proof person, and promote production according to customer needs. Although we have always emphasized software development and manufacturing industries, the software development industry that is in turn-related intersections is always constantly looking for the theory of rejuvenation from other industries. This approach is called Lean Programming. Lean-programming ideas include:

Eliminate waste. Anything that cannot add users recognized for the ultimate product is wasteful. Useless requirements are wasteful, useless design is wasteful, beyond the functional range, and the code that cannot be used immediately is also wasteful, and the workpiece is meaningless between different development groups. It is also a waste. Strengthen learning and encourage improvements. Software development is a process that constantly discovers problems and constantly solve the problem. The strengthening of learning ability can make improvements in software development work. Delay decision. Software Development If working in an undetermined environment, changes will cause harm to software development itself. Delayed decisions, when the environment has gradually clear, there is enough reason to make decisions. For software design, how to build a system that can support changes is a key issue. Delivery as soon as possible. Since the popularity of the Internet, the speed has become a critical factor in the business, which has directly affected the maturity of the rapid software development. The faster the software phase delivery is, the easier the software is, the more clean it, the more cleaning the user, the higher the quality of the software. Who makes decisions. Who makes decisions? Is a high-end senior manager, or an encoder who is close to the code. Decision depends on accurate information, but the authority of these information is often the coding personnel of actual work, incorporating the advice, decisions, and practices of the coding personnel into decision-making are the key to success decisions.

Lean Programming represents a kind of thought, and many of the Agile methods have set out this kind of thinking from their respective theoretical basis. In our discussion, the focus of discussion is on XP. The most valuable in XP method is his thoughts. We study, learn XP, can not be able to understand his practice activities, but also pay attention to the value of XP, and think carefully, behind the practice activities, what kind of thought is hidden. As we are in reading the design model book, the book gives a variety of object-oriented design methods, but there is still a main line in the book, which is the principle of object-oriented programming. process

For a few more time, the bookstore is very popular in most books and 6σ. 6σ is the development of comprehensive quality management theory. One of the most important ideas, and software development is that every step of the process will affect the final quality of the product, to improve quality, reduce costs, improve customer satisfaction, the most critical is to carry out the process Studies and analysis have found a large step of impovering the product and develop improvement measures.

A company specializing in takeaway, often being complained to the delivery of the customer is too slow. So they strengthen the power of delivery, including using better tools, hire more delivery personnel. But the cost is increased, and the customer's complaint is still constantly. Where is the problem? After quantifying the entire process, they found that the delivery time has a small amount of time, and more time is spent in the process of making takes. Therefore, the original investment of the delivery process is investment, it is considered a white fee.

Doing anything, you need to experience a process. The ordering phone from the takeaway is started, and a process has already started. Record the customer's address, address characteristics, dish name, order, distribute the foreign delivery person, transfer the address information to the foreign delivery person, send goods, find the destination, deliver the takeaway and pay the payment, and the subsequent process is ignored. An appearing life activity, which contains a complex process. The same is true for software development. From the customer's contemplation, the customer has always begun to use the software, and the process is very complicated, full of various unpredictable factors.

The process of sending a takeaway, each step will have an impact on the final quality (customer satisfaction). For customers, from calling to receive takeaway time, take-out is delicious, these are all composition ingredients. After receiving the phone, the customer's accent may be heavier, the recorder has heard the address, resulting in all the fake processes, unless the customer is impatient, calling to recover the address. After the order is given to the kitchen, it is possible to blow the list to the ground, and the customer's request is ignored. The recorder wrote the customer's address description information, the delivery personnel may not understand, this time he needs to call back, this will take the delivery time. Delivery personnel may not be familiar with the customer, find a lot of time. It's hard to send it to the customer, and the customer has waited impatient, worse, because the time is too long, the takeaway has been cold. Customers decided to replace a takeaway store next time. Although the probability of each contrary is not very large, after each link combines, the probability of an error is great. After analyzing such a process, our feelings often, actually can be sent, it is not easy! Isn't the software development process not this? Every link may have problems, and demand does not necessarily represent customers' needs. It is not possible to represent demand. Instead, add some unstable factors for encoding. Since the progress is tight, the encoding work is also more huge tiger. In this process, we can develop customers who are satisfied with the software, then only one explanation, the software developers who have been in contact with customers are more rotten than us. Ok, how do we improve this situation? Yes, improve the process. Since the recorder may have a mismatch between the client, we will ask the recorder to repeat it after listening to the customer's request. Since the menu may be lost, we specifically designed a location in the kitchen, arrange these menus in advanced order, and ensure that men will not be lost. Since the deliveryman may not understand the word recorder, let the deliveryman and recorders spend some time communication, or the shipper can get used to the word of the recorder, or the recorder wrote the deliveryman to understand word. Since the deliveryman may not have to know the road, then the delivery staff is drawn, there is special to send A, there is a special to send the B area, and each person is familiar with the scope, and the degree of familiarity will naturally increase. Ok, there is such a thought, we are also ready to improve the software process. However, not now, the remainder of this article will be carried out around this.

People in the process

In addition to the importance of the process, we still need to consider people's factors, the process is to rely on people to promote, no one, there is no meaning. This is the case for software development, and every link in the development process requires people's participation. There is never a way to focus on the role of people in XP. Therefore, in the full process of XP, human factors are always in the first place. The practice of XP is also carefully designed according to people's advantages and weaknesses. We do some simple discussions here:

Planning games: We often hang a sentence in the mouth is planning to catch up. Planning is often a heart disease in many software organizations. Everyone knows the importance of the plan, but the plan is the most difficult. There is no plan, the software process is not followed; there is a plan, the software process is often deviated from the plan. It is more difficult to change in more and more frequent changes. The attitude towards the tangible plan is that XP is: Conduct adjustment. This is as if we ride a bicycle, set a 500-meter goal, then we put the car fixed, select the starting point, and pre-set a good angle and standard route, then ride the car, strictly follow the original route. Can the car go to the end? The possibility is not big, there may be obstacles on the set standard route, this is what you didn't think of; because you can't adjust the direction to keep balance, the car may fall.

The car should ride like this. Look at the far goals, estimate distances and time, get a rough speed, then we will go to the road. In the process of advancement, we continue to visually visually visually visually visually detect the target, see time, and adjust the speed and direction. The goal is getting closer, our adjustment is increasingly proficient, and finally, we have successfully arrived the target point.

The traditional planning method is as unrealistic as the first kind of cycling method, and it is difficult to think a lot of things happened after a few months. It is only the correct attitude based on the constant adjustment of changes.

Note that it does not cost the time is planned, it is not equal to not paying attention to the plan. The plan is still the core of software development. You must have a current iterative plan, current week plan, or even current plans. Only to ensure the stringest of each small program, it can guarantee the success of the entire project plan.

XP's attitude towards the plan is: You don't need to do how precision do, but you have to do plan. It is planned to hurry up. This sentence is correct, we don't need to evade changes, spend great efforts to waste, and there is no meaning. But this is not to say not to make a plan. Everything is required, we need a simple plan, and then continuously correct and improve the plan during software development.

Learning Change: XP is best suited for those who are prone to changes in demand. In reality, we have found that this situation is too much. It may have a change in the target market of software, requiring software synchronization; possible customers have no sufficient understanding of demand, resulting in changes in demand; may have changed in the organization or business process, requiring software changes. Various possibilities indicate that development software is known as a luxury in a constant environment. In such a cruel environment, we have to go to learn the change.

Variations include two aspects: how the software process adapts to changes, and how software design is adapted. The traditional software process often requires the next software phase after determining the upstream software phase. However, the need to change require the software process to switch between multiple software stages.

Due to the cruelty of changes, XP recommends that developers must establish changes. You have to change your mentality, accept changes, change is reasonable, there is no existence that does not exist.

Here you insert a question outside. It is highly recommended to use object-oriented technology in XP projects. Although object-oriented does not have any requirements for software management or software management. However, an object-oriented team (note is the use of object-oriented technology, rather than using object-oriented languages, saying because there is a large number of developers using object-oriented programming language-oriented code), its management process It will also change. User participation, iterative development, reuse, and use the frame. These are naturally occurring changes after using object-oriented technology. Using object-oriented technology, it is possible to make a more tight connection with the XP method. In addition to the two simple ideas discussed above, other parts of this article discussions in the XP process and two factors in people.

Positioning of this article

This article is not an article introducing XP basic knowledge. This information has been much more information. If you want to fully understand XP, the XP series of XP series series of people's post and telecommunications is a very good start. The position of this book is to discuss how to apply XP in actual software development, how to follow XP's idea, but it is compromised according to the actual situation. Although this article does not introduce any XP basic knowledge, it is still suitable for XP's initiator to read. People who have just contacted XP often have a variety of confusion, but from foreign translations, they are not necessarily suitable for domestic environment, so read This article is able to understand the idea of ​​XP from the perspective of practice.

Like other methodology, XP is not universal. A software organization can benefit from XP, not depending on XP, but depends on this software organization itself. As we emphasized at the beginning, learn XP, the key is to learn ideas. Software organizations should be based on their own situation, learn, live in XP, not human clouds. XP is not making a pile of cards. Remember, remember.

The article has no comprehensive introduction to all the practices of XP. Because the author is not an absolute advocator of XP, we examine XP with an objective attitude, the content we introduce, is the experience after using XP's practice or absorbed the idea of ​​XP practices; we have not introduced some It is because the environment cannot be practiced or is not agreed (but it is not agreeable).

In fact, many of this article is not patented in XP, and other agile methods also mention these advantages, such as adaptive software methods. Therefore, more accurate description is how this article learns the advanced software development concept from XP.

(2) Assessment and evaluation

Spiral, iteration, increment, different nouns represent the same meaning - phased development software. Numerous methodology has used this idea design software process. However, in practice, more time, phased development software brings pain. It seems that we are often confused by the beautiful narratives in the book, but there is no problem that really wants to implement the implementation. So how do you manage the development of software in phases? How to deal with the problem in reality?

Assessment and evaluation

In performance management, there are two nouns: assessment and evaluation, respectively, in two performance management methods, respectively. What is the difference between the two?

We said that the assessment is a system, and the assessment is a process. How to understand? Many companies have a system of performance appraisal. This system is generally an assessment of employees at the end of the year. The assessment is a point. But the assessment is different, the assessment is aimed at the shortcomings in the employee work in a certain period of time, and it needs to be improved. Whether it is an assessment or an assessment, although they are designed to achieve the purpose of evaluating and improving employee behavior, the practice is different. Assessment for the past, it is easy to implement, but the effect is not good, because time is long, everyone may forget the previous things, and to be equally made to make a assessment of the past year, it is not an easy thing. The assessment is different, and the assessment is continuously carried out, and the evaluation of the just happened and found improved methods. It is like an example of our takeaway store in the first chapter, constantly analyzing and improves the process, which is an assessment. The evaluation is good, but it is difficult to achieve. Assessment and evaluation in software development

This idea is direct as the idea of ​​milestones and iterations during the software. We can think about it, milestones are not a system. At the end of the demand, we need a series of documents that require the statute document, risk list, etc., we also need other documents when design is over. This method of processing is the idea of ​​assessment. But many times, this assessment is limitless:

The workpiece is designed to assist in the generation of the final code, but it tends to be designed by a milestone;

Milestone design is not fully captured, some of the risk is hidden; it is difficult to evaluate workload and work value; milestones have exposed the problem of problems behind the problem of problems;

Here is some analysis of milestones. Our understanding of the problem is often gradually deepening. There is problems in business and technology at the beginning of the project, there is uncertainty and risk, which is often the most important assessment and verification. However, milestones often require in-depth analysis needs, and many problems are not resolved, but they are quietly intended to cover up. Demand is not software, it is a model of different people with different understandings. At this time, the roles in the project are different, but this does not affect their consistent decisions - through demand milestones. The problem is still in the design phase. Some of the problems hidden in the demand phase began to appear, resulting in some workloads. But all issues have not been resolved, and there is still unknown risks. So when will I expose? The most optimistic situation is found during the coding period, the most pessimistic situation is found during the delivery period. We call this process as the curing assessment process.

Where is the problem? In addition to the software itself, the model is good, the document will not be replaced by the final code. In lean principles, we said that waste must be eliminated. When we are developing a workpiece, our waste has arisen more or less.

With the curing assessment process, we believe there is another dynamic evaluation process. Milestones or checkpoints are not not important. But we need to convert ideas to make better practices in miletones. We mention that the biggest problem in mid ways is to wait until the problem has accumulated to solve the problem, and this time often missed the best time to solve the problem. The meaning of the dynamic evaluation process is to discover and solve problems in the process, rather than waiting to have a certain degree of mass solving. Process As the environment changes continuously, the process is constantly adjusted to adapt to the needs of variations and uncertainty. The milestone is focused on providing a review opportunity to evaluate the software from a higher level.

This process is the idea of ​​phased development software, and we can also call it iteration, spiral, increment, has no relationship. The key is that we need to discover the problem that the customer is not satisfactory, find the method of improving the phone, discovering the way to improve the food, and find faster delivery. Implementation strategy

The dynamic assessment process has some basic implementation ideas, the first basic idea is to discover all the questions as early as possible, how to find it? Perform an exploration process. This process cycle is not too long, too long cycle is easy to out of control, and the initial number of projects may not be able to all in place; but this cycle is not too short, too short cycle can't find sufficient risks, unable to provide subsequent processes Rich data.

Sometimes we use prototypes to implement this mini process. The prototype method includes a demand prototype and a technology prototype, which is used to solve business risks and technological risks. A typical demand prototype is to build an interface prototype to help customers understand future software and avoid abstract thinking. I have seen many interface prototypes, with HTML, have the use of the drawing software, using the usage of XML. But no matter what, the main type can help users can understand the needs. The main goal of technical prototype is to solve technical risks, and any project may exist like such or such technical risks. The basic attitude towards the risk is as early as possible to assess risks and develop solutions, rather than bunch. The solution of technical risk is determined by specific situations, but it is worth noting that a project is not too much in a project. If this is true, you want to find an experienced mentor or a trainer, which is better than yourself to save many costs.

XP's evaluation of the exploration process mainly includes two aspects, spike solution and iteration. Spike Solution is actually the technology prototype we mentioned above. Its purpose is to make an unclear assessment becoming a clear assessment (see spike in the XP process diagram). Only the assessment is accurate, the plan can be accurate. So it is an input item for plans and iterations.

As for iteration, it is an important concept in XP. Iteration Select the user needs (called user story) and designs, develops, tests, and iterates continuous repeat and solves a variety of problems. After passing by the user's test and recognition, a version that can be run is generated. This version is produced, marks a set of iterative cycles. The first small version is exactly the exploration process we emphasized. Its success and lesson is enough to let you understand the various knowledge of the project, including the complicated organization of the customer, the exact intention of the investor, find out all the people, discover the use case, make the team members and customers reach a preliminary consensus, verification Technical solutions, establish a preliminary software architecture, or preliminary mappings for existing architectures, programmers need additional training, the test power does not seem enough, the risk of deploying the environment needs to be resolved in advance. Only if you really do this in the complete life cycle, these issues will expose at the beginning, otherwise, many of them will give you a lot of trouble in subsequent phases.

The second basic idea is incremental development. What is the difference between incremental and iteration? Alistair Cockburn In the Surviving Object-Oriented Projects book, the incremental description is amended or improved development process, and the image statement is gradually completing software development. Note that the small version in the XP process diagram is an increment. XP believes that an increment should be available. It is good to do this, but not all projects can achieve this goal. For example, the first incremental target may primarily define an architecture, which does not include the functions required by the user, but it is the basis of project development. The architecture may include a series of frameworks such as a business entity infrastructure, a data manipulation infrastructure. However, for XP, it is not worth speaking on the framework that the user cannot find value is not worth it. The XP advocates is gradually improved the architecture based on the development of demand, rather than spending energy development architecture at the beginning of the project. It is difficult to evaluate which statement is correct, I prefer to spend an architecture design in the previous period, but in practice, it has been designed to be more complicated to lead to high cost. After spending a large amount of time, I found that in fact, the simple attribute can handle most of the situation, no doubt, the previous design is put into drift. Therefore, it is important to trade in the early stage of input. Ideally, you already have a reusable framework (or architecture) so that you can map the demand for the project to the frame, instead take time to develop a framework at the beginning of the project. If you don't have a framework, take a certain time to develop the architecture at the beginning of the project, but this time should not be too long, you can improve the architecture in subsequent increments, so you don't have to rush. Moreover, a simple framework (architecture) is not a way to perform testing, and your test has to postpone the second increment. This reason also promotes us to shorten the period of the frame design. It is iterative is improved or corrected software quality. This is also the third basic idea. We pay attention to iterations in the XP process diagram, multiple iterations constitute an increment (small version), each iteration is an improvement to the previous iteration, which may be amended, or demand defect . It is worth noting that new demand changes may occur in iterations (new demand or demand changes), and the project staff will understand the progress of the project (Project Velocity), which will in turn affect the planned correction. This reflects the attitude of our XP treated plan in the previous chapter.

There is no legal provision for iterative needs and incrementation, but it is obvious that combining these two ways is an effective approach. The goal of increment is to allow the project to advance (this is like the road, the length of the road is growing), and the iteration goal is to make the software quality better (just like a roadbed on a road, Wash cement, building pavement facilities). This makes us think of what, good, refactorful two hat. A hat is adding new features for software, and a hat is an improved software quality. Very similar, just one is the process level, one is the program level. There is a basic assumption here, do not increase function and improve quality. The team is also good, personal, once only one target efficiency is the highest.

Think

And traditional definition issues, then solve the problem of different practices, XP is highly refined from step-by-step. The problem definition and mathematics in software development is different. It is often blurred, dynamic, and needs to continue to adjust the problem in the process of solving the problem. For XP, this solution idea reflects its feedback - obtaining customers' feedback on software as soon as possible. (3) practice iteration

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.

Iterative problem

There is a story that is a person's stomach pain, go to see a doctor, the doctor gave 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 - "No silver bomb". Iterative and increment is not a silver bomb. It is not possible to do iterate, lack of excellent software design ideas and high software designers. In XP, it is highly emphasized that various practices are complementary. In my opinion, iterations can be reimbursed, test priority, continuous integration, etc. These practices reflect the relationship between software design and software.

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 iteration

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 can adapt 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:

Code design optimization

The ability of 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.

Delayed design decision

Lean Programming tells 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, demand changes, we ask us to increase extra behavior, we use the ConcreteDecorator class to add new features for ConcreteComponents:

Public Class Concretecorator Implement Component

{

PRIVATECITESENT;

Public void Operate ()

{

// Additional behavior

Component.operate;

}

}

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.

Pay attention to the interface, not paying attention to implementation

Martin Fowler divides software design into three levels: conceptuality level, implementation level, and implementation (IMPLEMENTATION). 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.

return

The software of version 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 the 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.

(4) demand and story

How to analyze demand, how to record demand, how to map demand into design, which is always the most important issue in demand analysis. XP advocates demand in a simple and practical attitude, and demand analysis is the most important workflow in the history of software development. Who is right?

story

Everyone likes to listen to the story, which may be the habit of developing from a small. If you can make the demand analysis work into the process of listening to the story, then how good it is. The demand analysts write a beautiful story, and the developers look at the story and the story is realized. Maybe this is the design idea of ​​XP. User story, XP turns demand into a story, abandoning boring and tasteless demand stability. The role of the document is to pass the information, if this sense is lost, there is no use of good documents. However, is it true that the demand document is really meticulous to meet the goal of communication? For most, I am afraid I have seen the thickness of the document. Ok, we can force developers to invest in a lot of energy to study and learn complicated demand documents. But this thick demand document really can record all the needs? Worse, the demand will change, how to maintain this demand document? Recall the principle of lean, we can determine that this way of processing demand will have a lot of waste. The cost of doing demand is perfect, and the project team is familiar with the cost of demand, maintaining the cost of documentation, and solving inconsistent issues. So, we can do an analysis for these points: Do you want to do it? The biggest goal of the demand document is to transfer information from the business person to the developer (of course there will be other purposes, such as part of the contract). So, whether the document is perfect and whether the communication effect is not directly related. How can developers can quickly understand demand? The production of documents is integrated into the maker's idea, so others have always taken a certain amount of time. There are two ways to solve the problem: one is to provide standard general practices; the other is to simplify the document, simple things are always easy to understand, but simple things are not easy. Maintain the cost of the document. Regardless, maintenance costs are always unavoidable, the key is whether this part can be reduced? Maintenance cost and number of documents, complexity is proportional, so the number of documents should be as small as possible, complexity is reduced. In addition, the number of times to reduce maintenance is also one of the key factors. When discussing the principle of lean, we say that as delayed decision-making is this.

In response to the above points, XP proposed its own ideas - user story. User story is simple, everyone will write, everyone can understand, it is easy to change. But the user story is just a simple description of the system function, and he does not provide all the requirements, so in XP, in XP, the practice of user story needs the support of the on-site customer. The reason why the user's story is simple, because it is just a contract between developers and customers, more detailed information needs to be supported through the site customers.

From the perspective of XP, the user story has such a few effects:

Customers describe themselves, write demand. For any requirement, the most ideal state is the needs of the developer professor customers. The worst case is that developers have written demand instead of customers. There is no doubt that XP requires the best practice. Customers must be able to develop demand themselves, and the prerequisites are to write demand, it should be simple enough, it is easy to master, or it is easy to master. User story is such a simple mechanism. The user's point of view. Excellent demand should be to think about the problem in the user's perspective. It is the user who can use the system, rather than the system. User stories are very good to reach this principle. Because the user story is written on his own position, it shows the user's expectations and opinions. Pay attention to the overall situation, not detail. The difference in demand has precision, the most critical development in the early stages of software development is an overview of a high-order demand, rather than immediate detail. For XP, the most important details of the demand are available through site customers. Field customers provide guidance on demand details at any time. Therefore, the focus of user stories is to completely discover demand as much as possible, and maintain a list of simple demand. The basis for assessment. The need for users to write provides a basis for the estimation of software. Although this basis is relatively thick, with the development of the project, the estimation of development speed will become more accurate. Appropriate estimates in the initial demand, the purpose is to make users have a more intuitive cost concept. This provides guidance for the order in which the user has developed demand. User's own co-ordination arrangement. Developing a user story is like shopping shopping, although each item is useful, but the order and quantity of the last purchase will depend on the thickness of the wallet. After each user story has cost (ie, the estimated estimation), the user can weigh the actual cost and needs and scheduled a seat. Iterative Plan input. The selection of users directly affects the development of the iterative plan. In the first version, users want to implement which needs (by choosing user story), it is estimated, these needs can be implemented in this release, How long is it takes to work. These are the impact of demand for iterative plans. Difficulty

When receiving foreign remittances, business people need to record information about remittances. If the payee account specified by the remittance is the Bank account, the account is processed, if the payee account belongs to the same city's peer (local other banks), then Through the same city's peers, the payee is handled?) If the payee account belongs to the same industry (other bank in the same place), the remittance transfers through the bank will transfer the remittance to the departure, and pay the account line transfer Fee (how to deal with it later?).

The above is an example of a bank's international settlement business. The short narrative and informal form embodys the simple principles that emphasize XP. The story helps developers and users' relationships. In the above example, we see that the development of the two sides still have certain doubts (ie in parentheses, there is a question mark in parentheses), but this does not affect the creation of the user's story, because this version of the user story will change multiple times. However, from this simple example, we find that there are still shortcomings in the form of the story:

The form of the story is easier to accept, but there are also irregular disadvantages. Any description of the needs of the description will save the cost of training, but it has caused a variability. Different people have different understandings about the story and have different understandings for demand. Negantity of demand is very simple, but it is necessary to talk about a demand story is definitely not an easy task. The demand statute is too formalized and formal, resulting in difficult to use, but do not do not have a good practice at all. Keeping balance between forms and usability, it is the key to demanding story.

Although the demand story is easy to read, it is difficult to write well. How to control the description of the description, how to decompose demand, how to organize, how to determine the boundary. But XP does not care about this problem, as long as it can function, how to do it. Whether this attitude is correct, we will not evaluate it. However, in practice, a novice often takes a long time to learn the story from the lack of system guidance. For XP, the development of demand is only divided. And the order of order is responsible for being responsible by customers. However, in practice, identifying the order is not just the responsibility of the customer, and developers also need to provide demand priority and risk recommendations. There are some suggestions for the priority here:

The main design is included, or a large number of business entities and typical business rules are included. For such a system representative demand, a high priority should be given. There are major technical risks in demand, such as the needs of the OCR development kit, and the development team has not been related experience. The demand includes important business processes, representing the main design ideas of this software. Demand is representative and it is difficult to estimate, urgently need to be tested for the need to obtain a more precise speed value. Time urgent for demand.

Use technology

Use case technology maintains the simple principles of demand, similar examples and forms and user stories very similar, but the use case has its own format, although this format is also defined arbitrary. The focus of use is to represent the behavior of the system. Let's take a look at how the examples are used in use:

Main role: Business staff level: Business process level front condition: Received funds Basic Process: 1 The business selection will return the remittance service. 2 Business people enter the necessary remittance related information. 3 Business people will transfer money to the payee account. 3.1 If the payee is the bank account, you will enter the account directly. 3.2 If the payee is the same city's peer (other banks), through the same city's peers to the payee (after proceeding?) 3.3 If the payee account belongs to the same industry (other banks in the same place), then through the bank The account line transfers the remittance to the off-site and pays the cost of the account line transfer (how to deal with it?). Alternative process is missing

It can be seen that the content and user story representing the use case are not too big, but the use case is compared to the format. Although different teams have different formats, in the same team, all steps in the basic processes are used in the same team (different use cases may require different use case formats) represent the business person and system once. Interaction, the process is very simple, but has covered a successful process. We see that every step of the process is highly abstract because the level of this use is the level of business process. (Business process level is just a convention, not standard). The use of the level is divided into the use case. In the above example, the main goal of the use of low-precision is to grasp the system of the system. In RUP, this use case is also referred to as a business case. In the original user story, the description of the branch is relatively vague, but this description of the use case is adopted, the branch situation is clear, as in front, there are many forms of expression of the branch.

Use the example technology from proposing now, there have been a lot of experience accumulation. It is not a new thing in the XP project. However, applications in XP must also follow the principles of XP and the idea of ​​lean programming. Fortunately, these ideas are very natural, and the use of use techniques is fully implemented. This article does not intend to describe the use of use techniques. If you need to understand the use of the example technology, there are several books that are very worthwhile (see Appendix). First grasp the whole picture of the system: When doing demand, a situation that often occurs is that the demand analyst spends a lot of mind to exceed the essence, improve an exemption. For XP, this practice does not recommend, and according to lean principles, this behavior has a waste of waste. Our understanding of the project is constantly in-depth. Therefore, we deepen the details, stories, or use cases at the beginning of the project, and the ability of analysts may be strong, and it is possible to capture the actual needs of users. But after a week, we have possible change in the understanding of the needs, perhaps the definition of the scope of the use case, maybe analyze the effect from another angle to analyze the effects, perhaps the idea of ​​the original handling case is incorrect. Regardless, the possibility of demand variation is very large. The more detailed use of the case, the greater the possibility of change. At this time, it was wasted when it was originally used in the extrigeration case.

Therefore, do not refine the demand at the beginning, the focus of the beginning of the work should be to put as comprehensive collection of use cases, understand the overall business process, analyze the main business process, etc. After obtaining the entire system of the system, you will find that you are not sufficient for your understanding of the system. The use case requires rearrangement according to new ideas. The priority of the use case needs to be adjusted. In the UML map, there is often a system for use. Overview, this picture is shown in an overview of system behavior.

Looking for a high priority high use: we mentioned above to the judgment of demand priority, and the priority judgment of the use case is similar. When we discuss ite, we said that the primary purpose of the previous iteration is to identify the risk of projects. Therefore, looking for a representative, high priority, high-priority, can help developer's faster understanding, and build a preliminary domain model.

Continue to the top international settlement example, after completing the total use case, we found that the bank's business is very complicated. If the area is missing, it is very difficult to trade in a short period of time. At the same time, we found that remittance The percentage of business in the daily business is very high, and the remittance business involves most of the domain knowledge, while business processes are relatively simple. Therefore, we decided to take the usage case of remittance as a breakthrough. After completing this use case, our developers will have more in-depth understanding of the business field, and they can make more complex work:

Main role: Business staff level: Business process level front condition: Received funds Basic Process: 1 The business selection will return the remittance service. 2 Business people enter the necessary remittance related information. 3 Business people will transfer money to the payee account. 3.1 If the payee is the bank account, you will enter the account directly. 3.2 If the payee is the same city's peer (other banks), through the same city's peers to the payee (after proceeding?) 3.3 If the payee account belongs to the same industry (other banks in the same place), then through the bank The account line transfers the remittance to the off-site and pays the cost of the account line transfer (how to deal with it?). Alternative flow 2. A At any time, business people can query the remittance bank at any time. 2. A1 After receiving the query response from the remittance bank, the reply information is recorded. 2. B At any time, the business personnel received the remittance bank asked to return the authorization of the remittance. 2. B1 If the remittance is not taken, returning the remittance bank as required. 2. B2 If the remittance has been taken, the notice bank cannot handle, the use case ends. Note that in this example, we have a slightly different cases of the use case priority and the above, we choose representative, but relatively simple use as a high priority. This is because it is more unfamiliar to the business field, and it is very difficult to achieve complex demand at the beginning. So, although we provide some ideas for developing use case priorities, it still needs to be balanced according to the actual situation.

Iterative refinement: The writing process of the use case is a process that is constantly familiar with the business. With the in-depth research, there is a continuous new problem revealed, and it is necessary to supplement or modify the original use case. There are two situations here, one is in the same increment, when the use case b is refinered, discovery is ignored in the use case A, which will need to add case A. For example, when we refine other use cases, we discovered the needs of the report in the exchange case, so our work must return to the remittance case. This is very common, which requires us not to excessively modify the use case, do not spend the energy in use case format, which only causes waste.

The second case is in different increments, this at this time will often join new demand, new situations. How do we control iterations during different increments? In general, there are two methods, one is to supplement the original use case, and the additional portion is used in different colors or marks. Another method is to establish a version for use, and the use cases of different versions correspond to different increment cycles. In this way, the corresponding use of N different versions of the use case (N ≤ N) corresponding to the N increment cycles. No matter which case, we have to use iteration ideas to handle the use case.

The form is not the most important: in the team, it is meaningful to write a uniform writing format, but sometimes, this significance does not think so much. You can agree on the conditions of the conditions, or the level of division can also be agreed. But there is no significance of excessive mandatory forms.

(5) Test management

No matter from that point, to ensure the quality of the software, the test work is less. Testing often is often ignored. For agile methods, lean programming, how to ensure the effectiveness of the test? How to reduce the cost of the test? It is two problems that are primarily considered in the test.

Testing process

It is not easy to do a good job. Testing work and software development is closely related, but the self-contained system. Test is not a separate stage or activity, the test itself is a process, has its own life cycle, starting from the test plan, the formulation of the test case, the structure design of the test code, test code. The life cycle of the test and the software development life cycle are screwed together, interacting. Of course, we are still the old saying that Rome is not built a day. For us, it is still from a simple start. When we talk about lean programming theory, the concept of comprehensive quality management has been discussed: every link in the production process needs to be responsible for quality, rather than leave quality issues to the final quality inspectors. This has a good reference for software development. The most headache in software development is quality problems because people's behavior is too uncertain. After a long software development cycle, the software gradually molds, but defects also slowly increase, trying to solve long-term accumulation problems in the final juncture is not a good practice. Software is developed to this time, discovery and modification of defects need to pay great consideration.

We said that the final test is not important, but software quality issues should pay attention to the entire software process.

Minimum unit of test

The important idea of ​​testing problems is on the management of tests, how to manage all tests in a project, as well as their related documents, related code, how to define testers responsibilities, how to coordinate the relationship between testers and developers ?

XP test priority and automation test practice is a very good practice, and we have also mentioned this practice more than once, but the unit test of XP emphasized, many people have some misunderstandings:

The examples provided in XP are too simple, unable to combine with the production environment. The unit test in XP only provides a specific operational idea for testing, but it does not replace other test principles. How to test, how to organize tests, how to manage tests, these are defined by different software organizations. The test code itself is not adapted to change. The ideal condition for black box test is that external behavior is not changed due to changes in internal behavior. When the demand or changes in the design, the internal behavior of a code needs to be changed, but external behavior does not need to change, so that the unit testing for external interfaces does not need to change, but this rule is violated, we need Pay the double price of the test code. Therefore, the design of the test code itself is very particular.

Unit test (sometimes referred to as class test) is a test level test, which is the minimum unit of test. XP value is very important to this minimum unit. We observe the test priority framework XUnit, found that it uses a combination mode to organize a large number of units of units to form a complete test network. Therefore, XP's ideas is very simple: the minimum unit test can be done well, and the system test can be done. This idea is not necessarily correct, but the idea of ​​paying attention to the minimum unit is absolutely correct. Each component is correct, the last software is not necessarily correct, but the component is incorrect, the last software must be incorrect.

Test priority

Test priorities and unit tests belong to the same practice in XP, but they are still distinguished. Test priority emphasis behavior, write test before writing code, the unit test mainly refers to the scope or level of the test. We said that test priority practice is really concerned, is not a test to be prior to code, the key is whether you can write a code suitable for testing, whether you can consider the design from the perspective of testing, consider code.

From another perspective, insist on test priority practice, you can consider problems from an external interface and client perspective, which ensures better connection between the various modules of the software system, and developers Thinking, it will also gradually implement it from simple considerations, transfer to the thinking of software structure. This is the real idea of ​​testing priority. Insisition to write test, just a measures to help you change thinking habits. For some excellent programmers, as long as it can reach the purpose, it is not the most critical. In fact, test is a difficult thing, because many times, we can't completely simulate the test environment, or the cost of completely simulate the test environment is too high. Software development is always carried out under a fixed time and cost, so we must use small cost as much as possible to achieve our key targets. Many of the books about the test are difficult to test, but in fact, there are many more contents that are difficult to test. For example, a business logic, which uses 14 business entities and some other classes, how to test it? With the Mock Object method, the cost of establishing the FixTure will be high, in addition, if the entity class is controlled (for example, the entity class can initialize the data instead of acquiring data from the database), this test costs It is also acceptable if it is not (for example, the technology provided by a third party), this cost will be higher. There are many similar situations, but why do you have these problems? One of the reasons is that we have not really putting test as an important part of software development.

Adhere to test priority thinking, can greatly reduce test costs. Modern software development often relies on specific middleware or development platforms. If these third-party products do not provide a powerful testing mechanism, it is often difficult to conduct a comprehensive test of the final product. For example, a JSP / Serverlet environment provided in J2EE, analog HTTP input and output is a difficult thing. If the test is not considered in the software design phase, the final test will be inch. However, in fact, if the problem is considered in the software design, it is not too much coupling between the business code and the environment control code. In this way, the test work can be done for independent business code, and this cost will be much lower.

Public Class Userlog

{

Public service ()

{

/ / Difficult to test code

/ / Need to test business code

}

}

It is noted that in the above example class, the code to provide services is divided into two parts. Part is a code provided by the framework, which is difficult to test simulation. This class has a lot of code, such as the processing of HTTPREQUEST, the data to simulate the data of HTTP It is more complicated. This increases the difficulty of testing. And this part of the processing is often the functionality provided by the platform and does not require testing. The second part is the key business code, which is the core of the test. So, on the one hand, it is difficult to build a test environment, and on the other hand, it is necessary to test the business code. Therefore, we naturally think of separating the business code to be tested:

Public Class Userlog

{

Public Static Void Write (String Name)

{

// Write into user information;

}

}

Public Class UserLogadapter

{

Public service ()

{

/ / Difficult to test code

Userlog.write (name);

}

}

In this way, the test can be performed for UserLog, because there is no need for a complex test environment, the cost of testing UserLog is very low. In the J2EE core mode, a refactoring idea to the business layer hiding a specific representation layer detail: Although the starting idea of ​​this reconstruction method is to avoid the details of the interface level to expose to the business layer, but from another A perspective, it also improves the testability of the business layer components. After all, build a user information, more easily than building an HTTPSerVeltrequest.

Therefore, the most reasonable introduction test is in the demand phase. The focus of the test work is how to define the test plan, how to define the acceptance test and obtain the customer's recognition, when the demand phase is completed, it must ensure that all the needs can be tested, all have test cases, the demand stage is another Important test tasks are preparing to build a test sandbox, build a test environment, and test data needed by this software project; in the design phase, the focus of testing work is how to define detailed test content of each module, the best way Implement the test code and build a test framework, and some test tools are needed for some complicated projects. In practice, we found that an extension of a test framework is a simple but practical approach. XUnit's focus is for automated testing provides a universal framework, capturing exceptions, logging errors, and failure, and manages Test Case and Test Suite using combined mode. In fact, there are still many jobs that can continue to be carried out on the XUnit framework, for example, is there a more common test case in software development? This way, you can define some abstract test cases and use this as the foundation of the test framework. For example, we hope that when we integrate daily every night, the test results can be sent directly to the person in charge through SMS, then we can embed this part of the function in the framework. These are accumulated on the test framework. For a software organization, it is necessary to spend time to accumulate the test framework. This simplifies the test workload and enhances the quality of the software.

Testing process

We have said that there is a process of testing itself. Although XP does not spend too much pen ink to describe your testing process, but after careful observation, we can find that there is also a test process in XP:

This process starts from the user story (or the use case recommended in the previous chapter), not only provides a demand for the version plan, but also provides test scenarios for accepting tests. For the acceptance test of customers, it provides feedback for each iteration, including BUG feedback and feedback of the next iterative information. Only the customer recognizes the acceptance test, the software can publish a small version. This is the highest level of testing in the XP process.

In the above, we mention that the best time to introduce tests is in the demand analysis phase. Because of the origin of the test life cycle - test plan and test cases require support. Let's refer to the process of RUP:

We see that RUP recommends starting testing activities in the first phase. Test activities in the early stage of the development process, the purpose is to improve the testability of software. Software Design If you have not been able to consider the testability of the software, the cost of the test will rise, and the software quality will drop. Sometimes, the unit test or component test is difficult. Therefore, we need to test testability for class or components. For example, for a component that implements a business process, there is a large number of status, events, branch selection and so on. The cost of component testing for such components is very high. If the testability can be considered in the component design, for example, the components are split into a sub-assembly having a smaller particle size, or the method of being used in the component is inserted in the assembly, the state of the component can be directly manipulated. It is the key to reducing test costs when designing. The source of design and testing is an analysis of demand in the first phase. The basis for the process of process component is exactly from the demand for the project. Some practices for testing

Strictly follow the first maintenance test, and then maintain the order of the code to achieve changes. In practice, a problem that the priority often happens is that when design changes affect test code, developers tend to bypass test code and directly modify the code.

When I just contacted the test priority ideas, I was strictly written in accordance with the premiere of the test, but when the code needs to be modified, sometimes some very small changes, this time I still maintain the original habits, directly on the code After completing the modification of the code, I suddenly realized that the test code needs to be modified, so I have modified the code, because it is just a small modification, I think there is no need to run test. This thing is soon being forgotten by me, but the hidden danger is buried. When two days after integrated test, the test program captured the error of this code. After debugging, it was found that simply modifications were neglected to ignore an extreme situation. Location errors, debug code, and through testing time far exceeds the time that is currently saving. Fortunately, the code is discovered in the next checkpoint (integrated test).

Improve the test network. When I learned and practiced the test priority, the team I was in the middle of the project, and there was a lot of code that did not implement the test, and I took the idea that the newly written code must follow new tests. Method, the old code remains status. Doing so can save a certain amount of cost, but soon we discovered that the put incentives were absolutely worth mentioning existing code. Plus the test code can quickly respond to changes, just this, it is worth rebuilding the test network. In addition, since the test is required, we have also found some interface definitions in the original code unreasonable or irregular.

In other projects, in additional starting projects, the problem that is often encountered is that with the progress of the project, the late test code is getting better and better. At this time, do we need to improve the original test code? The answer is yes, you will benefit from it. For automated testing, modify the test code and re-run the test, there is no bigger you think.

Perfect tests do not exist, but testing can be more and more perfect. In the beginning of the article, we mentioned the idea of ​​comprehensive quality management (TQM). TQM believes that each process of product production will affect the final product quality, everyone needs to be responsible for quality. For software development, any step of the development process will affect the software quality, to improve software quality, not to enhance the test power, it is necessary to ensure the quality of the software throughout the process. Building testing and continuously improving the testing behavior runs through the entire development process, providing a basic guarantee for quality. automated test

Automation test is another excellent idea of ​​XP test activities. When we discuss iteration, it was a brief discussion of regression and automation testing. Only the test is automated, the regression test can be achieved, and the reconstruction can be implemented, and iteration can also be performed. Therefore, XP has always emphasized that its practice is like a puzzle, only all implementations can fully show their charm. From this perspective, we can understand the meaning of this sentence.

For an automated test system, several parts are particularly important:

Data Preparation: For a simple TestCase, data preparation works in Setup (see junit), but the test data during real-world development is usually more complex, so it is necessary to prepare a separate data to provide classes. For a complete enterprise application system, often contain thousands of test cases, and the corresponding test data is also extremely large. At this time, we also need to have special mechanisms to generate and manage test data.

Test data and specific items are related to therefore there is no standard for establishing test data. So we see in the XUnit framework, the framework is just the activity of the establishment of data to abstraction and does not do additional processing. But for automated testing, it is necessary to establish independent test data for each unit. The independence of the test data is the premise of testing independence. Most of the test data is established in the form of scripts, including input data and output data. For example, for a business entity, you can use a script to assign a value for it. The script file has a lot of forms, such as configuration files, database data scripts, and more.

Verification: Verify that comparing the result values ​​returned to the method to be tested and the predetermined result value to determine if the method is successful. The result value is always matched with the input value, so we often put the result value and the input value in the same script. The relatively universal verification method is to use the assertion mechanism, and in addition, it includes error records, browsing test results, generating test reports.

Pile: Stub is a technique that is commonly used in automated testing. In OO design, class and classes often have a relationship, how do we test a separate test of a class that relies on other classes? There are many phenomena that are difficult to simulate errors in many software design. For example, an error is wrong, the network protocol error is difficult to simulate. The idea of ​​testing the pile is to solve these problems, a pile is not a real object, but it is possible to provide data or status of the object to be tested, so that the object to be tested can be able to use the dependence object, or analog events.

(6) Strengthen communication

Conclusion Programming is the last topic discussed in this series and a subject of controversial. Why is a person's work to be completed, this is a crime for the boss. Similar to the topic of the previous, we have to learn and apply a practice, and the key is to grasp the substance.

Communication is king

Communication issues are one of the most important factors for project success. A project may not have a formal software process, but as long as team members can conduct effective communication, the probability of success is very large, but if there is a lack of effective communication channels in the project, it is excellent, and the rigorous software process is not use. Excellent software methodology, always in the establishment of communication channels, driving a lot of effort to effectively communicate. We analyze RUP, XP, etc., and we will see a lot of such practices. Communication is important for a project, more important for a software organization. In the long run, there is a good development that can be developed in an effective communication, but in turn, there will be a lot of problems in the internal communication. A big problem in the software development process is the problem of communication. In fact, this problem is not only existed in a development process, and the long-term existence of the entire software organization and has become a major obstacle to hindering software organization development. This kind of saying may be too theoretical, but we only want to think that if a main programmer leaves, if a main programmer leaves, it will understand the meaning of this paragraph, and even organize a significant impact. The main problem caused by this phenomenon is that the program is dispersed in various programmers. Each code block is like a private property of programmers, and sacred cannot infringe.

More bad, any programmer is unwilling to read the code of others, compared to understanding the code of others, the programmer would rather rewrite the code, which leads to another serious problem - most of the work in the software organization They are repeated, so that programmers are busy with development code every day, but it is difficult to put energy in more valuable places (about what is more valuable, we will explain in detail below).

In some projects, we often see such a development environment: Each programmer has a personal separation space, and there is no communication between each other, and sometimes it doesn't say a word all day. After communicating with a main programmer in the project, we found their true thoughts:

The project is very nervous, the relationship between team members is very subtle, the main programmer must maintain its own main position, for them, we must work hard to write outstanding code, and you also need to take the pressure of the project, and Beware of other programmers. Master the program is the source of your own safety in your hand. The pressure is so big, they have to work more than 12 hours a day. Program development is like a nightmare.

Although not necessarily all teams are so bad, there are more or less have some bad environmental factors. It is certain that there is not much person to work in such a development environment. These environmental factors affect the formation of communication problems.

One of the four major values ​​of XP is communication. The communication range in XP has a wide range of communication between developers and customers (we also mention communication issues in the chapter of the needs and story), communication between programmers and designers, programmers and testers Communication between. However, this paper focuses on the internal development team, namely, how to improve the communication quality of the development team.

Improved Practice of Communication - Conference Programming

The XP methodology highly emphasizes to create a relaxed development atmosphere, and emphasizes the value of the people. Communication is a major value of XP. A large number of practices in XP is designed around this values. For example, user story, on-site customer, code collective ownership, etc., but we must emphasize here, it is a pair of programming. This article does not introduce the programming, there are many information in this area, and there is no need to waste the pen ink here. This article is discussed, which is how we consider the programming in the perspective of the project.

Ending programming is a very effective way to improve communication. A pair of programmers is the most basic communication unit in the collaboration process. In a classic XP method, the programming is the two programmers at the same time, before, the same machine, active common solutions. Perhaps the first reaction of the manager heard this sentence is: "This is impossible, I spent twice the money, but I only make a person's thing!" The efficiency is not only reflected in progress, but also in code quality, as well as project risk. Personal programming

Individual programming often encounters a variety of problems. In software development, writing code often only accounts for a small part of the construction process, and many time spent in debugging code, improving the code structure, and modifying the code for demand or design. Many people have to have such experiences, in some key technical issues, and single-person research not only cost time, but it is easy to lead to morale.

At othertions, programmers often need to trade out between different design seals, and a person who has made technical decisions often causes the inner disappointment. At this time, I hope that there is another companion to support you to make a decision.

It is said that the code is the most stringent workpiece is wrong. Any minor mistake, such as lack of semicolons, will cause an error in the program. Although the compiler can check most of the mistakes, there will still be some small mistakes that are hidden, when they come out. A person's eyes are often easier to miss some errors, but two people are coding at the same time, and this error will be greatly reduced.

In order to correct the debugging of code defects, the debugging work tend to occupy a lot of people. If the code defects have been found in the hands of the test team, the cost of modifying the defect will be high, and if the code defect has continued until the customer has been discovered, This price is even more amazing. The number of defects can be reduced by pairing developers. According to some data, the pairing programming can reduce the number of defects by 15%. It is also worthwhile to adopt a pairing program relative to the high cost of correcting defects in the software process.

The above discussion is some of the problems encountered in personal programming, which is a small problem, but will affect the mood of developers. In a team environment, these issues will expand and upgrade to team issues.

Team programming

Although software organizations specify software coding specifications, coding specifications cannot be agreed too thin, too thin coding specifications do not have operability. Therefore, the code written by the different people is still very different, the excellent code and the poor code exist at the same time. Everyone is familiar with their code, but it is not willing to touch the code of others. A variety of style code gradually produces the chaos of the code. This will have a lot of problems. First, the goal of the internal multiplexing of the software organization is difficult to implement. If everyone is not willing to see someone else's code, how do you build an internal multiplexed framework? The existing code cannot be controlled, the maintenance cost of the old project is constantly rising, and the team accumulation has also become an empty talk.

Second, the difficulty of code review is increased. The code review is a very important job, but the chaos of the code will increase the difficulty of code review, because the members of the review team have to spend time to understand the style of the code, and make guidance. Worse, members of the code review team are often important members in software organizations, and their time represents high cost. Perhaps no one has carefully calculated such a cost, but these costs accumulate, and it will be a surprising number.

Again, project risks and organizational risks increase. This is especially preferred in software development organizations in project development as a settlement unit, and the project source code is difficult to maintain due to the leaving of the project developers. For projects that have been completed, this has increased project maintenance costs. For projects that have not been completed, this will disrupt existing project progress, leading to the delay of project progress. Finally, it is also a fatal problem, and internal communication is difficult to carry out. Software development is not a separate activity. The team of excellent programmers is not necessarily a good team. For the reason, most of them are caused by non-communication. The knowledge inside the organization is difficult to form flow, and there is difficult to share knowledge between developers, and new members cannot learn from experienced old employees.

Communication is ultimately increasingly increasing the problem of forming the organization software design average. Software design is mentally labor, but personal knowledge coverage is limited, and personal design is often defective, and the cost of employed masters developers is quite high, not all software organizations can Have a lot of outstanding talents like IBM or Microsoft. Therefore, in the face of limited human resources (quantity and quality), the key issue is how to make the greatest role in limited resources.

Software process

After participating in the code review of a software organization, I joined the content of this section. Since it is a process, it is of course some very subtle links, such as browsing a collection of writing, classes, and methods of classes, rules of comments, and more. These are part of the programmer's own cultivation, but many organizations are just problems in this link. The arbitrariness of encoding has led to a decline in code understandability, setting an obstacle for team sharing code, and no one will take the initiative to see other people's code. In the front, we say that the chaos of the code will lead to the difficulties of review, and another impact of code confusion is simultaneously, that is, the average software process level of the software organization cannot be improved. Although each programmer wants to write a beautiful code, it requires certain perseverance and time to write a beautiful code, especially when the project time is high, the quality of the code is often ignored. However, forced code of code is not easy to achieve, and the cost of supervising is difficult to satisfactorily.

Conclusion Programming can ease this problem from the structure structure. Most of the programmer is proud. If there is a companion, the programmer can can't pull the face to write ugly code. This is very interesting, but it is quite effective. The programmer can promote each other and improve the level of programming process. Although software processes are solved by some tiny problems, it is these problems that eventually affect the quality of the software. From the perspective of code management, the basic tasks of management are these "small problems".

Process guarantee

Conference programming can ensure the minimum cost of resolving these problems, which is the reason why the programming is programming rather than three-person programming. The best solution for single-point failure is dual backup during the operation of the hardware device. This idea uses the foundation of the programming. We have seen a software organization to implement the title of programming is to ensure the safety of the product, and at least two heads are equipped on all important components of the product. At first they didn't realize that they took the first step towards the program, and then they found this method very effective and expanded to this method, forming a complete pairing programming system.

In traditional software development, several check points are generally created during software. At this point, all parts of the software need to check, design whether or not, whether to meet the requirements, whether there is existence in the program defect. But the time spent on each Check Point is often terrible. The work covered in each CP includes:

Familiar with others' design ideas and code style will integrate different systems to improve defects.

And the practice of programming is actually the cost of this part of the cost to everyone in every person. Through two and two mutual match, let all people in the organization can be familiar with the various parts of the software. This cost is indeed higher at the beginning, but with the deeper's dedication, this cost will slowly decrease. According to the information, the relationship between the program is not like most people, it will increase 100% cost, which depends on the specific implementation form, but will never be 100%. (7) actual combat

The fundamental idea of ​​programming is to improve the quality of communication inside the development team. In actual conditions, different development teams face different communication problems. So how do you find a common guidance idea, how should you adjust according to the actual situation?

Cost weighing and strategy selection

From the discussion of the previous article, we can understand that due to the factors, ideal changing programming often has a lot of resistance. At this time, we can adjust according to the actual situation, choose different ways. But how do we evaluate the cost of these ways? There is a problem in the modification of design knots, test knots, review, and the like: It seems that they seem to have achieved the effects of the pair, and saves costs. But in fact, this cost is not saved, but it is transferred.

In the project, in order to give the junction, it is easier to accept for programming, and we use a variant practice, and when designing and reviewing, the code is responsible for a single developer. A and B have two hours of design discussions for a requirement, and then be responsible for encoding by b. However, b was found in the case where the original design was found, and he decided to make some modifications to the design. At this time, he wants to notify A, but at this time A is not, then B is adjusted according to his own ideas, and Complete the implementation. At the time of review, B had to spend a period of time to explain the reasons and details of design changes.

Note that during this process, the time A and B saving the encoding of the encoding, it is actually transferred to the review. Of course, the time spent on review may be much shorter than the coded time. But we must also see that if there is a defect in the design, A and B still need to spend a certain amount of time to improve design and implementation, this situation is also a big possibility.

The discussion of the cost of the programming is not the next conclusion. This cost is uncertain for different organizations. For some organizations, the ideal pairing programming may be very suitable, but it is not necessarily for other organizations. The focus is that a method must be found so that the communication skills between the team are enhanced.

The standard when the different teams perform in a way design is only one, which is how to improve communication quality. Different teams have different communication problems. Find this communication problem can we be able to medicate medicines. There is such a software organization, and he implements the idea of ​​programming is very simple, it is to reduce the impact of the mobile phone. After study, we have found that this organization has such a feature: the product has experienced the evolution of several generations, the structure is complicated; developers understand only the modules that you are responsible, very small, and have a fixed customer base, customers There is often a need for modification; any developer's loss means that the module he is responsible is unmanned for a while; the cost of increasing a developer is acceptable relative to the embarrassment of the module. In such a case, the organization requires any module must have two developers responsible. In fact, after this approach, the personnel did not double, because the work of maintaining old products and developing new products is parallel, but also the same developer is not only responsible for one module. Although the personnel have increased, the customer's satisfaction is improved, and the development force is also enhanced, and this result is still satisfactory. It can be seen that in this example, the pairing method is not a pair program described in XP, which is just an organizational form, but in solving communication problems, the idea of ​​both is similar. Similarly, if we want to apply a knot in your own organization, it is less than the work of the communication bottleneck of your organization.

Design

The meaning of the design is that the design of a certain module is completed, and the design here is not a large-scale software design (for large-scale pre-design, we prefer to let the team design, please refer to agile architecture design), Instead, it is designed before the code, this design is characterized by a short time (only a few hours or dozens of minutes), but it is very important for the quality of the entire code, because we need Guaranteed the principle of designing the architecture, as well as design flexibility, consistency, etc., also need to ensure the performance and speed of the design. After a feature is completed and entered the encoding, this part of this characteristic has been determined. Therefore, this small scale design is often a more important fine point in software development. Configure double in design and can effectively improve code quality. This pairing idea is on critical components, but the specific performance of small-scale design is often two people 's views of a problem. He does not reflect in the form of code or model, The constraints of the non-coder are relatively small, and the code implementation is likely to be inserted and designed, so that non-implementing is difficult to obtain this knowledge. In this way, if used alone, it is easy to evolve into a form, and the effect is not very good. Therefore, we need other cooperation.

Test

The test knot here is tested to the special finger unit. The basic idea of ​​champion is that the A and B have agreed to the class profile (class structure and public method), and a written test code, b writing code to meet the test. If B is incorrect for the design understanding, the code must not be tested, if the understanding of the design is incorrect, B must notify A Rewind test. If the change of XP's unit test is very familiar, it will have a good effect in this way. First, the test code itself is a small scale design, and it reflects in a specified coding. As long as the test code is excellent enough, it can capture a lot of design defects. Second, this way is a variant of a limited test, but its effect is superior to a single person's test priority. Because a person thinks about testing and design, it is difficult to consider, if two people consider, tests often find more problems or defects. When you start using this method, you may be a bit not habit, but it will be more smooth after you are familiar. Review

Designing and testing pairs are paired before the coding activity begins. However, the review is done after the encoding activity is completed. A After b Completing the code, you need to review the code. The contents of the review include whether the code reflects the intention of the design. Is there a defect in the code, whether the code meets the demand, whether the code meets the principle of consistency. Generally, this review belongs to the same level review. Of course, based on the organizational style discussed below, you can guide experienced programmers to guide unreportable programmers. The maximum meaning of the review on the software process is that it has formed a continuous review system that retains the advantages of the review system, and can overcome the disadvantages of the review system. For example, it takes time, and is blindly rejected by the developer.

The two ways of these ways can be implemented separately or can be implemented. Although these three ways are not complete in programming practices, they get as much as possible to the programming benefits, and the cost is relatively low. If you have started to implement a pair programming or there is no sufficient resource adopting a pair programming, the above variation is used.

Commonly programmed organizational style

The pairing program is not catching. Members' organizations need certain skills. Basic operation ideas are, first identify the key issue of communication, and then start, organize personnel. For example, for a project, participating developers have less experience, developers are unfamiliar with the development model of the organization, and are also unfamiliar with the development of the target. The main tasks are pressed on the experienced senior programmer. In order to solve this problem, in several iterations of the project, it is enforced the pairing system. The basic idea of ​​pairing is a newbie, the pairing realization is the old hands to write unit test, require novice implementation, and joint code review (ie Use test knots and review patches to two ways). After completing a small module, the older needs to replace his partner to ensure that the newbie can make more independent development work when the first two iterations are completed. The progress is very unsatisfactory. The old hands also have varying degrees of complaints, think this is in delays. However, the senior management personnel listened to the report of the project, expressed support for this approach. After all the newcomers are mixed with the old hands, the situation has changed very much. The development speed of the system is significantly accelerated. The atmosphere of close communication is formed, and the veterans can make more complex design and quality control, and more surprisingly, there are already two newcomers to get close to the veteran, This means that the next round of pairing programming process, they will play the role of the older.

This example tells us:

Implementation of important communication issues on programming a problem with a problem with programming is an excellent practice designed for communication issues and environmental characteristics, must insist on

This is a very typical organizational style that can be applied to a lot of software projects. It fully reflects the importance of communication. More organizational styles also include: Training projects. Sometimes this project is also known as a gribbezable project, the biggest goal of the project is to study and test certain techniques to promote the technology within the software organization. In this project, knowledge exploration and research tend to be more important than cost, so it can be used in the form of a programming. QC. During software development, there is often a core part of the design. This part of the design is either related to the overall structure of the software, or it means the most concerned demand for customers. This part of the software design is good, will directly affect customer thinking about software. Therefore, this part of the design is worthy of double development power. In many projects, we have found that many developers don't realize this. For developers, they may just have some negligible mistakes, but these mistakes sometimes allow customers to leave a very bad impact. Therefore, identify important parts in the software and invest more development power, often enable the final software quality. Relocation system. Studies have shown that even better tissue doing the knowledge management, there is still a lot of knowledge to be stored in the human brain. In order not to form an information from one by islands, the best information flow is to communicate. Turning system, or Cross Training, is designed to solve this problem. Another problem solved by the root system is that it is not a busy person who has neither a busy group. This is a problem that manages important solutions, and the round government can solve it very well.

(8) Miscellaneous

XP also has other excellent practices. This article discusses the other three practices of XP and study how to use them flexibly in the project.

Code collective ownership

XP advocates that the code home collective, this reason is that everyone can modify the code, not waiting for others to modify the code. This approach can effectively avoid the gap between code. But the collective code ownership is also its problem.

We tried the practice of sharing code by multiplayers, with the purpose of strengthening communication, avoiding a case of only one code to know. This method is working very well, but soon we found a lot of problems, the definition of the class became unclear, some classes became bloated, we smelled the taste of "Large Class". It is even more bad that these classes and reconstruction are quite difficult because they have too much customers. It is because these classes are widely used, so everyone has modified and expanded, resulting in chaos of the code. So, we have increased the effort to review and reconstruct these classes, but new problems have emerged, it is difficult to find a balance point, which can keep the team's agility and guarantee the height of the class. Availability. Worse, different people have different understandings and expectations in these classes, resulting in these types of design styles.

In this article, we are not only emphasized, and all practices in XP are used in conjunction. The ownership of the collective code in the project is not not good, but there is a premise. In the above example, we made at least a few mistakes:

There is no tacit understanding between team members. Only the level of knowledge between team members is similar, or have similar thinking, for example familiar with object-oriented, familiar with design patterns. This can only assume the quality of the code together. In the project, we tried a new approach to narrowing the range of collective ownership to group, which consists of three to four senior developers, called a core group, responsible for building a foundation framework. This group uses an efficient shared code mechanism. Other developers use the results of the core group to work, they do not modify the core code, but can provide amendments. Ignore the quality of code. Different people modifying the code is more likely to decline in code quality than single modification code. This cost must be considered and find out the quality of recovery code quality. The review is a very effective means that the FDD (Feature Driven Development feature driver development) method emphasizes the role of review in the project. As long as the cost can accept, more review is not too much. Code standardization. The code standardization mentioned here is not only code specification. It also includes code whether or not the code is readable, whether the structure of the code is sufficiently clear. These can lead to form a chaotic when the team is collectively owned by the code. In addition, it should also be noted that the collective code requires frequent integrated code. The code must be quickly synchronized and integrated, and shared code often means that the same package, the same class may be modified simultaneously. This greatly increases the possibility of introducing bugs. It is necessary to make a synchronous code as soon as possible.

If a software organization does not solve these problems, it is dangerous to use collective code ownership. Instead, consider using personal code ownership or micro team code ownership. The former said that the individual is responsible for the individual's code, the latter is said that two to four people are responsible for some of the code.

Whether it is ownership of personal code or the micro team code ownership, its foothold is a clear developer responsible for the code, he guarantees the unified design idea and style of the code, responsible for the client interface, responsible for maintaining and improving the code, responsible for code Related documents, responsible for explaining the operational mechanism of the code. Personal code ownership is the clearest approach, but its disadvantages and collective ownership is just the opposite. A person's code may cause the bottleneck of progress, and anyone will leave the team will cause loss.

Personal code ownership is easy to understand, but the micro team code ownership needs special explanation. His organizational ideas are very similar to our organization's organizational style advocated in programming:

Different people are responsible for different codes, and there is a cross between personnel. Such organizers are flexible, and the programming is the same as the work of the programming.

Continuous integration

In the document of the continuous integration of Martin Fowler (the Chinese translation of this article can be found on the Agilechina website), there is such a description of the continuous inheritance:

There are a variety of "best practices" in the field of software development, and they are often talked, but there seems to be rarely realized. These practices are the most basic and most valuable: there is a fully automated creation, testing process, allowing the development team to create their software multiple times a day. "Day creation" is also a view that people often discuss, McConnell creates Japan as a best practice in his "Fast Software Development", which is also a development method that Microsoft is famous. However, we support the view of XP community: day creation is just the minimum requirement. A fully automated process allows you to do multiple creation multiple times a day, it is also entirely worth it.

As with other practices mentioned herein, the main idea of ​​continuous integration is to inherit the software of the software process to the entire process of software. Although there is no way to judge the cost of two duration, continuous integration can get a lot of additional benefits. The most integrated place for a single integration is the process of bugs, especially those hidden, and people feel that there is no bug. If the write code is a kind of enjoyment, the process of repairing the bug is definitely a torment. Time spent in this process is sometimes amazing, worse, this part of the time is not estimated, which makes the project manager headache. The response to the encoder inquiry will always be "a little bit". Continuous integration avoids this embarrassing situation, due to the short time, the problems in the integration can be easily discovered. Even if you don't locate an error, the worst case can also be integrated into the software. In this way, the quality of the software will be relatively high. In addition, another important task of continuous integration is to run automation tests, ensuring that all code is tested, and there is no problem. The test here is derived from unit testing, in this article, you can find a more detailed discussion.

For some teams that have not continuously integrated experience, the continuous integration is a very high cake of a hanging, but it can't see it. It is not easy to do continuous inheritance, but we can use the continuous integration of ideas to approach the continuous integration goals.

The best practice for continuous integration is the construction and testing of automation. This requires that the software organization has a good configuration management mechanism, as well as the rich test script to write experience. For a corporate application (sorry, I only have this experience), software design includes many factors, and it is not an easy thing to take these factors in the process of continuous integration. Therefore, many organizations may lack these two factors, but there is no relationship, we can use semi-manual way to complete continuous integration, then slowly integrate process automation. Here is a semi-automatic continuous integration idea and improvement process.

The first is to define duties. If you use code non-collective ownership, then specify each class or package (for process language is a function and module), responsible team (or individual). Similarly, you also need the person in charge of the specified database mode. There may be a crossed place between these codes, but there is no relationship, just guarantee communication, a small amount of cross-duty is not particular. It is best to specify a person who is responsible for continuous integration, allowing the different people in the project to alternately serve as the responsibility.

Secondly, the automation code is defined. All tests must be written in the form of test code and can run. All database mode definitions must also be written as DDL, not using database tools. Don't steal this lazy. The general principle is that you can write a code, only the code is available. I admit that the workload is very big, but this is necessary.

Once again, it is defined in the integrated frequency. Frequency development depends on the mass and communication quality of the team. For a small team, an integration of an hour is also possible. For large projects, you can divide the sub-teams, and the sub-teams are frequently integrated (one hour), and the sub-team is integrated (once every day). With the integration guarantee of the sub-team, the integration of the entire team generally does not have any problems.

Next is the use of tools. The most needed is that version control tools can be used, such as ClearCase. You can also choose from, for example, SourceSafe, you can also use free (CVS). There is no relationship, the key is whether it is suitable. The integration of code and documentation passes this tool, and the database is integrated through the database administrator (that is, the first step specified by the person responsible for database mode). The integrated person in charge is responsible for coordinating the integrated process to ensure the success of integration. Finally, there is a problem, this is just a beginning, you will have a variety of problems in the process of integration. For example, integrated time, data correlation, design coupling degree, and changes in test code. There is no relationship, there is an adaptive process here. At the beginning, the continuous integration process must be wrong, slowly will stabilize, this is an improvement time, the main goal of improvement is always automation. Sometimes, in order to ensure the quality of integration, we ask for a wrong person, please eat ice cream, don't laugh, this is part of the process, this is a very effective, everyone will seriously guarantee the test before submitting the code. .

Code standard

The code standard is a very basic management common sense. But we don't intend to add a problem with the code standard. We will focus on discussing the development standards. Development standards include a wide variety of standards. For example, the logo of the process, the standard, standard model of design model, code style standard, variable naming standard, case case standard, etc. In XP, it is actually not very emphasized, because XP advocates simple practices, but sometimes standards are often violating this norm because it will bring additional standardization costs. The reason why the weight level method is cumbersome, and it is a major reason.

But in the actual process, I think I would rather invest more resources in the implementation of the standard. This is related to the actual situation in China's current software development. After the lightweight method of abroad, most of the programmers have experienced mandatory standardization. But China is different, although the lightweight method is very good, but understands or improper execution, it often leads to the consequences of the painting tiger. The development process of many software organizations in China is still in a state of disorder, and developers also have a fresh experience in the standard process. In such cases, blind advocacy is practical, in fact, in fact, there is still a chaotic state.

Therefore, standard development and implementation is always worthwhile, although there will be a certain cost, but this cost is also the benefit of the improvement to promote accumulation, etc.

But the standard development is definitely not to specify the time of the toilet on the toilet, how to maintain the standard balance is the focus of agile methods. XP believes that the code specification is enough. But I think there are at least several criteria that need to be paid:

Document Standard: This is a big topic, the best document standard is UML. A picture is better than a thousand words. UML will become more and more powerful after UML2.0. Therefore, it is necessary to use UML instead of the document. There are a lot of information about UML, and there is not much discussion here, but there is an advice about UML is that do not try to use the UML all types of diagrams at the beginning, do not use UML all features. This approach, and the characteristics of the words processor, there is no difference with the practice of non-writing documents.

Design standard: It is also a big topic. Design standards include how to design, how to represent design, how to design architectures, how to design all levels, etc. Implementing the design standard in an organization is a long-term process. But it is still that sentence, it is always better than not doing.

Code Standard: XP is very readily readable, and the code readability represents the level of programmers, and the designer's efforts. Best practices in improving code readability are reconstruction and review, and these two practices have detailed discussions in other locations herein. Interface standard: Interface standard is sometimes only a small problem, but for modern software, the interface is playing more and more important roles. In the field of soft workers, the key to excellent interface is consistency. The same buttons must have the same size, position, and font. It is very important to develop a interface standard.

How to develop standards: The standard development does not require a lot of explanation documentation, these documents are difficult to understand, and how many people will see, even if they see it, they may not understand. It can only be wasted. The best way is examples and training. Description of the documentation is written in a document example and a short description. Re-adjusted with face-to-face explanation, its effect is far more than the documentation.