12 Practices to Fully Follow in Extreme Programming

The 12 practices of extreme programming are the practice classics summarized by extreme programmers. They embody the principles of extreme programming management and are of guiding significance to extreme programming. However, it is not necessary to fully comply with the 12 practices. The main point is the value it brings to software process management.

1. Small Version

In order to be highly iterative and show the progress of development with customers, the small version release is a good way to communicate, and customers can provide feedback in a targeted manner. However, the small version shrinks the module very little, which will affect the overall coherence of the software, so the small version also requires proper planning.

2. Planning Games

It is the customer's demand, which the customer writes in the form of customer stories. Extreme programming does not focus on a unified collection of customer requirements, nor is it sorted out by developers. Instead, it allows customers to write, developers to analyze, set priorities, and carry out technology implementation. Of course, the game's rules can be played many times, and they can be modified after each iteration. Customer stories focus on communication between developers and customers and are the basis for version design. Therefore, their management must be effective and have smooth communication.

3. On-Site Customers

Extreme programming requires the customer to participate in the development, and the customer writes the customer needs. Therefore, the customer must work together at the development site and provide feedback for each iteration.

4. Metaphor

Metaphor is to make project participants have a consistent understanding of some abstract concepts, which is often referred to as industry terminology because developers are not familiar with the terminology of the business itself. Customers do not understand software development terminology, so it is important to start by clarifying the metaphors used by both parties to avoid discrepancies.

5. Simple Design

Extreme programming reflects the tracking of customer demand changes. Since the demand is changing, it is not necessary to consider the development of extensibility too much for the current demand. It is only necessary to focus on simple design and realize the current demand. The simple design itself also provides convenience for short-term iteration. If developers consider more "common" factors and increase software complexity, the development iteration cycle will be longer. The simple design includes four meanings:

• Pass the test.
• Avoid duplicate code.
• Clearly express the purpose of each coding step, and the code is readable.
• As few object classes and methods as possible.

Because of the simple design, there are no complex design documentation requirements for Extreme Programming.

6. Refactoring

Refactoring is an inevitable requirement for extreme programming to test first and then code. For the overall software to be tested first, the modules to be developed by some software should be simulated first so that the compilation can pass and achieve the purpose of testing. Then the module is specifically "optimized," so refactoring includes optimizing the module code and developing the specific code. Refactoring is a concept that uses "physics," which is to re-optimize its in-house mechanism without affecting the external characteristics of the object. The external characteristics here are to ensure that the test passes.

7. Test-Driven Development

Extreme programming starts with testing. The test program is designed first to show the realization of customer requirements. Testing is based on the customer's practical perspective and the customer's actual software interface. Testing is the direct expression of customer requirements and the customer's understanding of the software process. Test-driven development is the development of software driven by customers' needs.

8. Continuous Integration

The understanding of Integration is the presentation of submitted software. Since test-driven development and small version are adopted, continuous Integration (comprehensive testing) is the basis for communicating with customers and the reference for customers to give feedback. Continuous Integration is also a sign of completing the phase development task.

9. Pair Programming

This is the most controversial practice of Extreme Programming. Pair programming is when two programmers share a computer to program, one to code, and one to check. Adding a special audit is to provide the quality of software coding. The roles of the two people frequently change to maintain the developer's enthusiasm for work. This programming method has a very good effect on cultivating new people or developing complex software.

10. Code Sharing

There is no strict document management in extreme programming, and the code is shared by the development team, which is conducive to the flow management of developers because all people are familiar with all coding.

11. Coding Standard

Coding is the work of everyone in the development team, and there is no detailed document, so the readability of the code is very important. And it is necessary to specify uniform standards and habits, which is a bit like a coder metaphor.

12. 40-hour-a-week job

Extreme programmers believe that programming is a pleasant job, and it is not easy to work overtime. Today's work is done, and the small version is also designed for work arrangements that can be completed per unit time.