Lightweight and smart Extreme Programming (XP)

ExtremeProgramming (XP) was proposed by KentBeck in 1996. KentBeck worked with wardcunnheim in the early 1990s s to explore new software development methods, hoping to make software development easier and more effective. Kent carefully observed and analyzed the various prerequisites, possible actions, and difficulties for simplifying software development.

ExtremeProgramming (XP) was proposed by KentBeck in 1996. KentBeck worked with wardcunnheim in the early 1990s s to explore new software development methods, hoping to make software development easier and more effective. Kent carefully observed and analyzed the various prerequisites, possible actions, and difficulties for simplifying software development. In March 1996, Kent finally introduced a new idea of software development-XP in a project for DaimlerChrysler.

XP is a lightweight and smart software development method. it is also a very rigorous and thorough method. Its foundation and values are communication, simplicity, feedback, and courage. that is, any software project can be improved from four aspects: strengthen communication, start from simplicity, and seek feedback; be brave in seeking truth from facts. XP is a near-spiral development method, which breaks down complicated development processes into relatively simple small cycles. through positive communication, feedback, and a series of other methods, developers and customers can clearly understand the development progress, changes, issues to be resolved, and potential difficulties, and adjust the development process in a timely manner according to the actual situation.

Extreme Programming-what is software development

Software development involves requirements, design, programming, and testing.

1. Requirement: not only the user requirement, but also all the requirements encountered during development. For example, you first need to know what the project is to solve; what data should be input in the test case ...... To clearly understand these requirements, you often need to communicate with customers, project managers, and so on.
2. Design: Before coding, you must have a plan to tell you what to do and what the structure is. You must follow this process, otherwise it may be a mess.
3. Programming: If your program cannot run or meet the customer's requirements on the project deadline, you will not be able to get the money.
4. Test: The purpose is to let you know when it is finished. If you are smart, you should first write the test so that you can know if you have completed it in time. Otherwise, you often don't know which functions are actually completed, and how far is it from the expected goal.

In software development, customers and developers have their own basic rights and obligations.

• Customer:

Define the business priorities of each user's needs; develop an overall plan, including the amount of investment, duration, and purpose; and each working week during project development, can maximize the benefits of investment. by repeating the function tests you specified, you can accurately grasp the progress of the project. you can change your needs, functions, or priorities at any time, and avoid expensive re-investment; the project plan can be adjusted in a timely manner based on various changes; the project can be canceled at any time; when the project is canceled, the previous development work is not a pile of garbage, and the functions that have been developed are required, ongoing or unfinished work should not be difficult to take over.

• Developers:

Know what to do and what to give priority to; work efficiency; receive answers or help from customers, colleagues, and superiors when there is a problem or difficulty; evaluate the work, and re-assess in time according to the changes in the surrounding circumstances; actively undertake the work, rather than passively accept the distribution; 40 hours a week, no overtime.

This is software development, and there are other concerns.

Extreme Programming-core idea of XP

In the long run, early error detection and complexity reduction can save costs. Extreme programming emphasizes dividing tasks/systems into sub-tasks/modules that can be solved in a short period of time, and emphasizes testing, code quality, and early issue discovery. Generally, through short iteration cycles, we can get progress in stages and form a version for your reference in a timely manner to respond to possible changes to your needs.

Extreme Programming-twelve methods of XP

1. The Planning Game)
2. Pair programming)
3. Test)
4. Refractoring)
5. Simple Design)
6. Collective Ownership of Code (Collective Code Ownership)
7. Continuous Integration)
8. On-site Customer)
9. Small Release)
10. 40-hour Week)
11. Code Standards)
12. System Metaphor)

Extreme Programming-four core values of XP

Four core values of extreme programming are worth noting in development: Communication, Simplicity, Feedback, and Courage ).

XP uses "communication, simplicity, feedback, and courage" to relieve development pressure and burdens, regardless of the terminology, content and methods described in the monograph, and process requirements, you can feel the relaxed, pleasant, and active attitude and atmosphere. This is a means to help you understand and stimulate people's potential more easily. XP, with its own practice, successfully broke the traditional idea that software engineering can succeed only by weight.

The XP spirit can inspire us to learn and deal with fast-changing and diverse development technologies. The key to learning XP successfully is to treat XP with a "communication, simplicity, feedback, and courage" attitude; feel XP's practical thoughts easily and happily; after you practice it carefully, analyze the real feedback to determine the value of XP to itself; have the courage to accept it, or improve it.

Extreme Programming-smart lightweight software development method

A software development method consists of a series of development-related rules, norms, and practices. Heavyweight development methods strictly define many rules, processes, and relevant documentation work. The smart lightweight development method has fewer rules and documents, more flexible processes, and easier implementation.

Before the emergence of software engineering concepts, programmers developed software in their preferred ways. The quality of the program is difficult to control, the debugging program is cumbersome, and it is difficult for programmers to understand the code written by the other party. In 1968, EdsgerDijkstra wrote a letter to CACM entitled GOTOStatementConsideredHarmful, which led to the birth of the concept of software engineering. Programmers began to abandon their previous practices and instead use more systematic and rigorous development methods. In order to make control software development as strict as control of production of other products, many rules and practices have been developed one after another. many software engineering methods have been invented, and the quality of software has been greatly improved. As there are more problems, the rules and processes become increasingly sophisticated and complex.

Today, in the actual development process, many rules are difficult to follow, many processes are complicated and difficult to understand, and the document production process in many projects is out of control. People try to propose a more comprehensive and better package, or hope for more complex, more powerful auxiliary development tools (CaseTools), but it will always fail, in addition, development specifications and processes become increasingly complex and difficult to implement.

In order to catch up with the schedule, programmers often skip some specified procedures, and few people can fully follow those heavyweight development methods.

The cause of failure is simple. there is no panacea in this world. As a result, some people propose to delete, restructure, and optimize the rules and processes in heavyweight development methods, which leads to a lot of lightweight processes that adapt to different needs. In these processes, rules that meet actual needs are retained, and unnecessary complicated development rules are discarded. In addition, compared with traditional development methods, lightweight processes are no longer more flexible than flow production lines.

ExtremeProgramming (XP) is such a smart lightweight software development method.

Why is it called "Extreme" (limit )? "Extreme" (limit) means that, compared with the traditional project development method, XP emphasizes that every method and idea listed in it is the ultimate and the best. What other XP does not advocate, ignore all (such as the overall design at the early stage of development ). For a project that strictly implements XP, its development process should be stable, efficient, and fast. it can work 40 hours a week without delaying the project progress.

1. Extreme Work environment

To maximize and fulfill the basic rights and obligations of customers and developers during software development, XP requires that the working environment be the best. Each person who participates in project development will assume a role (project manager, project supervisor, etc.) and fulfill corresponding rights and obligations. All people work in the same open development environment. it is best for everyone to work in the same big house with refreshments. they do not advocate overtime for 40 hours a week. every morning, everyone stood up and held a short meeting. There were some large whiteboards on the wall, and all Story cards and CRC cards were pasted on them. during the discussion, they could write and draw on them; after work, you can play computer games .......

2. Extreme demand

The customer should be a member of the project development team, rather than separated from the developer, because the customer plays an important role from the project plan to the final acceptance. Developers and customers turn various requirements into small demand modules (UserStory). For example, "calculating the total number of grades means accumulating the number of students in all classes of the grade ."; These modules are combined or decomposed into smaller modules based on actual conditions. they are recorded on small cards (StoryCard, it is then implemented by programmers in every small cycle (Iteration, usually no more than three weeks); customers specify their priorities based on the commercial value of each module; what developers need to do is to determine the development risks of each requirement module. the high risk (usually due to lack of similar experience) requirement modules will be prioritized for research, exploration and development; after developers and customers evaluate each module from different perspectives, they are arranged in different development cycles, and the customer will get a development plan as accurate as possible; the customer specifies an acceptance test (function test) for each requirement module ). Each time the software is released (after a development cycle), you can get a ready-to-use system that fully meets all the requirements in the corresponding plan. In some traditional development modes, no matter what function, the user must wait until all development is completed.

3. Limit design

From the perspective of specific development, the internal process of XP is one by one based on the test-driven development cycle, such as the planning and design of the outer process is centered on this. Each development cycle has many UnitTest instances ). At the beginning, all unit tests failed because nothing was implemented. as small demand modules were completed, more and more unit tests were passed. In this way, both the customer and the developer can easily check whether the customer has fulfilled its commitment to the customer. XP advocates simple design, which is the simplest way to allow programs written for each simple requirement to pass all relevant unit tests. XP emphasizes abandoning the detailed design package (BigDesignUpFront), because there is a lot of content that you don't need now or recently. XP also strongly advocates Review, code Review, and refecement and optimization. all these processes are actually optimization design processes; continuous unit tests and functional tests during these processes can ensure that the restructured and optimized system still meets all requirements.

4. Extreme Programming

Since programming is very important, XP advocates that two people write the same program together (PairProgramming), and the ownership of the code is attributed to the entire development team (CollectiveCodeOwnership ). Programmers must strictly abide by programming specifications when writing and reorganizing optimization programs. Anyone can modify the program written by others. after modification, make sure that the new program can pass the unit test.

5. Limit test

Since testing is important, XP advocates writing unit tests before writing programs. Developers should integrate developed modules frequently (ContinuousIntegration) and run unit tests each time after integration. unit tests should be run for any code review and modification; if a BUG is found, you need to add the corresponding Test (so the XP method does not need a BUG database ). In addition to unit testing, integration testing, function testing, load testing, and system testing are available. All these tests are one of the most important documents in the XP development process and one of the content that is finally delivered to users.

Extreme Programming-important conventions and rules in XP

Project development Team ):

In XP, everyone who contributes to the project should be a member of the project development team. In addition, at least one person in this group must have a clear understanding of user needs, be able to propose requirements, determine the commercial value (priority) of each requirement, and adjust the project plan based on changes in requirements. This person assumes the "customer" role. of course, it is best to be the actual end user, because the entire project is based on the needs of the end user. Programmers are essential members of the project development team. There can be testers in the group who help customers develop acceptance tests; there are analysts who help customers determine their needs; there is usually a Coach (Coach ), it is responsible for tracking the development progress, solving some problems encountered in the development, and promoting the project. It can also be another project manager, who is responsible for allocating resources and assisting in communication between the project and the outside. There are so many roles in the project team, but it doesn't mean that everyone does the work that others cannot intervene or intervene in. XP encourages everyone to contribute as much as possible to the project. Get along with each other and learn from each other. this is the best XP development team.

PlanningGame, acceptance testing, and small-scale release)

The XP development team uses a simple method for project planning and development tracking, and predicts the project progress and determines the future steps. Based on the commercial value of the demand, the development team should conduct a series of development and integration based on the needs of a group. each development produces a tested and usable system.

PlanningGame)

The XP development team uses a simple method for project planning and development tracking, and predicts the project progress and determines the future steps. Based on the commercial value of the demand, the development team should conduct a series of development and integration based on the needs of a group. each development produces a tested and usable system.

XP's planning process mainly targets two problems in software development: how much work can be done before the delivery date; what to do now and next. Continuously answering these two questions is to directly serve the implementation and adjustment of the development process. In contrast, it takes half the effort to precisely define what to do in the entire development process and how much time each task will take. To address these two problems, XP has two major processes:

1. Software release plan (ReleasePlanning ). The customer elaborated on the requirements and the developers estimated the development costs and risks. The customer develops a general project plan based on development costs, risks, and the importance of each requirement. The initial project plan is neither necessary nor possible, because the development costs, risks, and importance of each requirement are not static. Moreover, this plan will be constantly adjusted to be more accurate during implementation.
2. IterationPlanning ). During the development process, there should be many stages (for example, every three Monday ). Developers may perform internal restructuring and optimization (code and design) on the system at a certain cycle, while new functions are added at a certain cycle, you can also perform two tasks at the same time in one cycle. However, after each development cycle, you should be able to get a system that has implemented some functions. In addition, each time the customer goes through a cycle, the customer will come up with the need to determine the completion of the next cycle. In each development cycle, developers break down requirements into small tasks and estimate the development costs and risks of each task. These estimates are based on actual development experience. if the project is done too much, the estimates are naturally more accurate and accurate. in the same project, every time a development cycle occurs, the next estimation will have more experience, reference and basis, so as to be more accurate. These simple steps provide rich and sufficient information for the customer to flexibly and effectively control the development process. Every two or three weeks, the customer will be able to see what the developers have done. In XP, there is no vague saying that "it's almost finished" or "it's finished 90%". if it's not done, it's not done. This approach seems to have advantages and disadvantages: the advantage is that the customer can immediately know what has been done, whether the made things are used together, and what needs to be done or improved; the disadvantage is that the customer may be dissatisfied or even suspend the contract when they see what they have done. In fact, this practice of XP aims to discover and solve problems as soon as possible, instead of waiting for a few months until the user finally sees the developed system, then I will tell you what I can't do, what I changed, what I want to add, and so on.

Acceptance Test

The customer defines acceptance tests for each requirement. Through the acceptance test, developers and customers can know whether the developed software meets the requirements. XP developers regard these acceptance tests as important as unit tests. To avoid wasting valuable time, it is best to automate these testing processes.

Frequently released small-scale software (SmallReleases): the demand for each cycle (Iteration) development is what users need most. In XP, users should be able to easily evaluate the systems that are released at the completion of each cycle, or have been able to put into practical use. In this way, software development is no longer invisible to customers, but tangible. XP requires frequent software release. if possible, a new version should be released every day, and a new version should be released immediately after any change, integration, or new requirement is completed. The consistency and reliability of these versions are ensured by acceptance testing and test-driven development.

Simple design, PairProgramming, test-driven development, reorganization and optimization

XP programmers not only work together as a development group, but also write the same program for a small development unit. Developers perform simple design, write unit tests, and then write code that meets the test requirements, and continuously optimize the design while meeting the requirements.

Simple design: This is what puzzles beginners in XP. XP requires the simplest way to achieve each small requirement, provided that the software developed based on these simple designs must pass the test. These designs can only meet the current needs of the system and customers, without any superfluous design, all these designs will be continuously reorganized and optimized in the subsequent development process.

In XP, there is no general design that is one-time in the traditional development mode for all requirements. In XP, the design process almost always runs through the entire project development: from developing a project plan, to developing an Iteration plan for each development cycle, to a simple design for each requirement module, to design review and continuous design reorganization and optimization. The whole design process is a spiral, continuous development process. From this perspective, XP is designed to the extreme.

PairProgramming: in XP, all the code is written by two programmers on the same machine. this is the most controversial and difficult to implement in XP. This ensures that all code, design, and unit tests are reviewed by at least another person, and the quality of code, design, and testing is improved accordingly. This seems to be a waste of human resources, but research shows that the opposite is true. -- This method greatly improves the work intensity and efficiency.

Many programmers are forced to try this at the beginning (XP also requires administrative command support ). At the beginning, I was always not used to it, and the efficiency of two people is not higher than that of one person. The effect of this approach is often significant after several weeks or one or two months. According to statistics, 90% of all the programmers who started PairProgramming thought this work method was more efficient two months later.

During project development, everyone will constantly change their partners in cooperative programming. Therefore, PairProgramming not only improves the software quality, but also enhances the knowledge exchange and update between them, and enhances the communication and understanding between them. This not only benefits individuals, but also the entire project, development team, and company. From this point of view, PairProgramming is not only applicable to XP, but also to all other software development methods.

Test-Driven Development: feedback is one of the four basic values of XP-in software development, sufficient feedback can be obtained only when sufficient tests are passed. The tests proposed in XP can be seen in other software development methods, such as functional testing, unit testing, system testing, and load testing, XP integrates testing into its unique spiral incremental development process, and testing continues to accumulate as the project progresses. In addition, because the entire development team has code, testing is also maintained by everyone. That is, anyone should run all the tests before putting the program (CheckIn) into the code base. anyone who finds a BUG should immediately add a test for the BUG, instead of waiting for the person who writes the program to complete; anyone who takes over the task of another person, or modifies the code and design of another person, if all tests can be passed after the change, it proves that his work has not damaged the willingness system. In this way, testing can truly help get feedback. Moreover, through continuous preparation and accumulation, testing should basically cover all the customer and development needs, therefore, developers and customers can get as much feedback as possible.

Refactoring: XP emphasizes a simple design, but a simple design is not a streamlined program without design, nor a program without structure or reusability. Although developers have a simple design for each USERSTORY, they are constantly improving the design. this process is called Refactoring ). This name first appeared in the Refactoring: ImprovingtheDesignofExistingCode written by MartinFowler.

Refactoring is primarily intended to reduce repetitive parts of the program and design, enhancing the reusability of the program and design. Refactoring is not the first concept of XP. it has been proposed for nearly 30 years and has been regarded as one of the features of high-quality code. However, XP emphasizes that Refactoring should be Refactoring at any time, anywhere, and whenever possible. as long as it is possible, programmers should not feel bad about the previously written programs, but should improve the programs without mercy. Of course, after each change, the programmer should run the test program to ensure that the new system still meets the predefined requirements.

Frequently integrated, collective-owned code (CollectiveCodeOwnership), programming specifications

XP development teams often integrate different modules. To improve software quality, apart from test-driven development and PairProgramming, XP requires everyone's code to comply with programming specifications, and anyone can modify the code written by others, and everyone should take the initiative to check the code written by others.

Frequent Integration: in many projects, developers often integrate modules very late. In these projects, developers often find many problems in the integration process, but they cannot be sure who has a program Problem. Besides, after the integration is complete, the developer starts to use the entire system a little and then immediately delivers it to the customer for acceptance. For the customer, even if these systems pass the final acceptance test, the customer is not sure about the use time.

To solve these problems, XP proposes that the USERSTORY that has been developed should be integrated as frequently as possible throughout the project process (a new USERSTORY should be integrated each time ). For each integration, the corresponding unit test and acceptance test should be run to ensure that they meet the requirements of customers and developers. After integration, a new application system is released. In this way, a new system will be released almost every one or two days throughout the project development process, and sometimes several versions may be released one day. Through this process, the customer can clearly understand the completed functions and development progress, and communicate with developers in an effective and timely manner based on these situations to ensure the smooth completion of the project.

CollectiveCodeOwnership: in many project development processes, developers only maintain their own code, and many people do not like others to modify their own code at will. Therefore, even if there may be more detailed development documents, a programmer is seldom and unwilling to read the code of other programmers. Moreover, because it is unclear what functions the program of others implements, a programmer generally does not dare to modify the code of others. At the same time, because you maintain your own code, some problems may not be found or solved due to time shortage or technical limitations. To address this, XP advocates that everyone has code, and everyone has the right and obligation to read other code, discover and correct errors, and reorganize and optimize code. In this way, the code is not only written by one or two people, but completed by the entire project development team. errors will be much reduced, reusability will be improved as much as possible, and the code quality is very good.

To prevent system crash caused by code modification by others, everyone should run the test program after modification. (From this point, we can see again how XP's practices and rules are organically combined .)

Programming specifications: everyone in the XP development team follows a unified programming standard. Therefore, all the code looks like it is written by one person. With unified programming specifications, each programmer can easily read the code written by others. this is one of the important prerequisites for CollectiveCodeOwnership.

5 Metaphor (system analogy), no overtime: the XP process uses image Metaphor to give everyone a common and concise understanding of the system. XP considers overtime as abnormal because it indicates that there is a problem with the estimation and arrangement of the project progress.

Metaphor (system analogy): to help everyone understand customer requirements and system functions to be developed in a consistent and clear manner, the XP development team uses many Image metaphors to describe how a system or function module works. For example, for a search engine, its Metaphor may be "a large group of spider looking around the internet for something to capture and then bringing it back to its nest ."

Don't work overtime: a large amount of overtime means that the original plan is inaccurate, or the program is far from clear about when the job can be completed. In addition, developers and customers cannot accurately grasp the development speed, and developers are also very tired. XP believes that if there is a lot of overtime, developers (such as Coach) should work with the customer to determine the cause of overtime and adjust the project plan, progress and resources in a timely manner.

Introduction to some basic concepts in XP

• UserStory: developers require customers to write all their requirements into independent stories, each of which can be completed in just a few days. During the development process, the customer can propose a new UserStory at any time or change the previous UserStory.
• StoryEstimates and development speed: the development team estimates each UserStory and calculates the development speed repeatedly based on the actual situation in each development cycle (Iteration. In this way, developers and customers can know how much UserStory can be developed each week.
• ReleasePlan and releas.pdf: Throughout the development process, developers will continuously release new versions. Together with the customer, developers determine the UserStory contained in each release.
• Iteration (development cycle) and IterationPlan: in a Release process, developers require customers to select the most valuable UserStory as the development content for the next week or two.
• TheSeed: After the first development cycle (Iteration) is completed, it is submitted to the customer's system. Although this is not the final product, it has implemented several Story that customers think is the most important, and developers will gradually add new modules based on it.
• ContinuousIntegration: assemble the developed UserStory modules one by one to approach and ultimately complete the final product step by step.
• Acceptance Test (function test): For each UserStory, the customer will define some test cases and developers will automate the process of running these test cases.
• UnitTest: before writing a program, a programmer writes a test program for most classes.
• Refactoring: removes the redundant part of the code and increases code reusability and scalability.

Extreme Programming-changes brought by XP

Simple and beautiful software designed through software engineering is no more valuable than software that is complex and difficult to maintain. Is this true? XP does not think so.

A typical project spends 20 times the amount of time spent on hardware, which means a project spends $2 million a year on programmers, it only costs $0.1 million on computer devices. Many smart programmers say: "We are so smart that we find a way to save 20% of hardware overhead." Then they make the source program large and difficult to understand and maintain, and they will say: "But we saved 20% or 20 thousand US dollars each year, which is a huge savings ". On the contrary, if we write our program that is simple and easy to expand, we will save at least 10% of the manpower overhead and save a lot. this is something that your customers will pay attention.

Another important issue for customers is the program BUGS. XP not only emphasizes testing, but also requires correct testing. Tests must be automated to provide a secure environment for programs and customers. In all stages of coding, we are constantly adding test cases. When a bug is found, a new test is added, and a tight security net is generated. The same BUG does not appear twice, which will surely attract users' attention. Another thing your customers must pay attention to: XP developers embrace demand changes. XP allows us to accept changes in requirements.

Generally, the customer can understand the system only after it is developed. XP is different. it shortens the development cycle by enhancing customer feedback, and gets enough time to change features and gain user recognition. In XP, your customers should be clear about this.

Most of the revolutions in the XP development process are in the software development method, and the importance of code quality exceeds what people generally think. Just because our customers cannot understand our source code doesn't mean we don't have to manage the quality of the code.

Extreme Programming-when do we use XP

The XP method is generated because of the difficult to manage demand changes. from the very beginning, your customers did not fully know what the system they wanted, the functions of the system you may face have changed several times a month. Changing requirements in most software development environments are the only thing that remains unchanged. in this case, XP can be used to achieve an impossible success in other ways. The establishment of the XP method also aims to solve the risk issues in software development projects. If your customers need a very difficult system to develop within a specific period of time, and this system is a new challenge (never done) for your project team ), the risk is even greater. if the system is a new challenge for the entire software industry, the risk is even greater. using XP can reduce the risk and increase the possibility of success.

The XP method is developed for small groups, ranging from 2 to 10. If your group is the right one, you don't need to use other software engineering methods, but you should be aware that you cannot apply the XP method to development projects of large groups. We should note that, in a project with dynamic or high risks, you will find that the role of the XP method in the development of small groups is much higher than that in the development of large groups.

The XP method requires an extended development group. The XP group includes not only developers, but also managers and customers. all the work involves a link, asking questions, discussing methods and schedules, add function tests. solving these problems involves not only software developers.

Another requirement is testability. you must be able to add automatic unit tests and functional tests. However, when you perform this requirement, you will find that many problems are hard to be tested, this requires the full use of your testing experience and wisdom, and you sometimes need to change your design so that it can be easier to test. Remember: if there is a requirement, there should be a test method.

In the list of benefits of the XP method, the last one is productivity. In the same cooperation environment, XP projects consistently demonstrate much higher productivity than other methods. But this is never the true goal of the XP methodology. The objective of XP is to produce software that meets the customer's needs at the specified time. If this is an important aspect for your development, you can select XP.

Extreme Programming-effective practice of Extreme Programming

1. Complete team

All participants of the XP project (developers, customers, testers, etc.) work together in an open place where they are members of the same team. The walls of the place are displayed with large, notable charts and other things that show their progress.

2. Plan game

The plan is continuous and gradual. Every two weeks, developers estimate the cost of candidate features for the next two weeks, while customers choose the features to be implemented based on the cost and business value.

3. Customer test

As part of selecting each desired feature, the customer can define an automatic acceptance test based on the script language to indicate that the feature can work.

4. Simple design

The team maintains that the design exactly matches the current system functions. It passes all tests and does not contain any duplicates. it expresses everything the author wants to express and contains as few code as possible.

5. Pair Programming

All product software is built by two programmers sitting side by side on the same machine.

6. Test-driven development

Writing unit tests is a verification and design behavior. Similarly, it is a kind of document writing behavior. Writing unit tests avoids a considerable number of feedback loops, especially feedback loops for functional verification. Programmers work in a very short cycle. they first add a failed test and then make it pass.

7. Improved design

Use the refactoring method to improve corrupted code at any time, and keep the code as clean and expressive as possible.

8. Continuous integration

The team always makes the system fully integrated. After a person pulls a Check in, the other owner is responsible for code integration.

9. Collective code ownership

Any paired programmer can improve any code at any time. No programmer is solely responsible for any specific module or technology, and everyone can participate in any other development.

10. Encoding Standard

All the code in the system looks like it was written by a single person.

11. Metaphor

A global view that connects the entire system. it is the future image of the system, and makes the position and appearance of all the separate modules obviously intuitive. If the appearance of a module does not match the entire metaphor, you will know that the module is incorrect.

12. Sustainable speed

Only a long-lasting team can win the game. They work hard at a speed that can be maintained for a long time. they save their energy and think of projects as marathon, rather than full-speed sprints.

Extreme Programming-summary

One of XP's success factors is to focus on customer feedback-the purpose of development is to meet the customer's needs. The XP method enables developers to confidently face changes to customer needs. XP emphasizes teamwork. Managers, customers, and developers are all members of the development team. By fully communicating and cooperating with each other, the team strives to develop high-quality software in a simple but effective way like XP. The design of XP is simple and efficient. programmers get customer feedback through testing and modify the code and design based on changes. they always strive to deliver the software to the customer as early as possible. XP programmers are brave enough to face the needs and technical changes.

XP is like an intelligent puzzle made up of many small pieces. it makes no sense to look at each piece separately, but after it is assembled, a beautiful picture will appear in front of you.

This article is available at http://www.nowamagic.net/librarys/veda/detail/1213.