Part I agile development chapter 1 eXtreme Programming Overview

As developers, we should remember that XP is not the only choice. -- Pete mabreen
★2.1 extreme programming practices
Extreme Programming is a well-known agile method. It consists of a series of interdependent practices.

★2.1.1 customer as a team member
Customer definitions in XP: define product features and list people or groups with priority for these features. It may be a Unified Business Analyst and market expert of a company, a user group representative, or a person who pays for development.
The closer the customer and developer are, the easier it is to integrate into the team.

★2.1.2 user Material
Specific requirements:
In order to record the project and understand the project requirements, but not too much, you can record it.
The specific details of the requirement will change over time, especially when you see the integrated system, premature capturing of details will lead to useless work;
In XP, we repeatedly discuss with the customer to get an understanding of the requirement details, but do not capture those details. We record them with short words to help the collection, and developers will mark the estimation while recording.
User stories (user stories): It is a plan tool for user requirements. The customer schedules the implementation time of the requirement based on the priority and cost.

★2.1.3 short delivery cycle
Deliver workable software every two weeks to meet stakeholder needs, demonstrate and get feedback.
Developers set a budget for this iteration based on the workload completed in previous iterations.
Plans are divided:
Iteration plan: a two-week plan.
Release plan: Six iteration plans.

★2.1.4 Acceptance Test
The acceptance test is completed before or at the same time the user material is implemented.
The acceptance test is written in a script language that enables them to run automatically and repeatedly. It can be compiled by developers or QA departments.
The ever-increasing acceptance test is run multiple times every day.
★SlS: I used to be confused about unit testing tools such as JUnit. I didn't realize the importance of Automated unit testing until I recently attached great importance to product quality. To ensure product quality, we need to prepare a large number of test cases. The ideal status is these test cases, covering all the actual use cases. Therefore, the use case library is huge. Previously, testers directly operated on the user interface and found bugs. In this way, the efficiency is relatively low. However, the problem is that all the use case libraries should be executed for each product version release, every bug modification, or code modification, function addition, and efficiency optimization to ensure quality without any derivative errors. Manual testing is obviously inefficient when versions are frequently released. In this case, automatic unit testing will greatly improve the test efficiency, no matter how powerful the test case is.
Big, don't worry. This is also why struts2 is better than struts1, because struts2 is independent of containers and can perform automatic unit testing. Struts1 cannot implement this function.

★2.1.5 Pair Programming
One person controls the keyboard encoding, And the other observer looks for errors in the Code and improvements.
Benefits: improve efficiency, reduce defect rate, and greatly promote the spread of knowledge in the team

★2.1.6 test-Driven Development Method
All products are written to pass unit tests.
Test Cases and code are constantly evolving.
In order to pass the unit test, decoupling becomes an inevitable choice.

★2.1.7 Collective Ownership
No programmer is solely responsible for any specific module or technology.

★2.1.8 continuous integration
Every programmer will continuously check in and out.

★2.1.9 sustainable development speed
Software projects are not sprints, but marathon. The team must consciously maintain a stable and moderate speed.
XP rules do not allow overtime, except one week before version release. This is because the goal can be achieved overnight.

★2.1.10 open workspace
The full status icon, task details, and UML diagram are displayed on the wall.
In a room full of active discussions, productivity will not decrease, but multiply.

★2.1.11 plan game
Planning games are essentially divided into the responsibilities of business personnel and developers. The business personnel (that is, the customer) determine the feature, and the developer decides the cost to achieve this feature.
At the beginning of each iteration or release plan, developers provide customers with a budget based on the last workload. The customer selects user materials whose total costs do not exceed the budget.
In this way, the customer will soon understand the project progress and cost.

★2.1.12 simple design
The XP team makes the design as simple and expressive as possible. They will not consider future user materials. This means that the database or middleware may not be used at the beginning, and will be introduced only when a user material needs the infrastructure.
The following XP principles guide developers:
1. Consider the simplest thing to do.
The XP team is always looking for the simplest design that can implement the current user material.
A flat file is connected to a database or EJB, a socket is connected to orb or RMI, and multiple threads are connected to a single thread.

2. You will not need it.
Only evidence shows that the introduction of the infrastructure is ahead of schedule when the introduction is more cost-effective than a period of time.
★SlS: This is the same as my tuning principle. Only when we are certain that a bottleneck will definitely happen or it has already occurred can we tune it, rather than determining whether the problem can happen, solve the problem.

3. Once, and only once.
Repeated code is not allowed in extreme programming.
There are many factors that may lead to duplication. Common reasons are copy and paste.
Methods To eliminate repeated code include defining functions or base classes or using template method.
The best way to eliminate duplicates is to abstract them.

★2.1.13 Reconstruction
With the addition of a feature that handles one error, the code structure will corrupt, but ignoring it will lead to tangled and difficult to maintain code.
Refactoring is a series of small changes to the Code without changing the code behavior. It aims to improve the system structure.
Run the unit test after each transformation to ensure that no damage is caused. This ensures that the system can work.
Rebuild continues. It takes one hour and a half an hour.

★2.1.14 metaphor
Metaphor is a global view of the entire system. It is a future scene that makes the position and appearance of all individual modules obviously intuitive.
Metaphor can usually be attributed to a series of symbolic names that provide a vocabulary of system composition elements and help define the relationships between them.

★2.2 conclusion
Extreme Programming is a set of simple and specific practices. These practices are combined to form an agile development process. Is a common and excellent software development method.
The project team can use the service directly, add the practice, or modify the practice to use the service.