Extreme programming, usually XP, is a rule for business and software development, where its role is to focus on the power of the two, can achieve the goal. The XP team produces quality software in sustainable steps.
XP is a method in which the lightweight development method is more affected.
The XP method emphasizes customer participation and testing. In XP, the role of the client and programmers is clearly defined. They are in the same team, but they have to do different decisions. The customer decides "what the function he wants", the programmer decides "how much cost is". You can clearly distinguish what you do.
XP programmers write code using the incremental programming method of testing. Write a part of the unit test case and write code that meets the test requirements. There is always a test to prove the correctness of the new code. Program in incremental, and test first.
A program can run and does not mean it has been completed. XP does its best to maintain the system's greatest adaptability by maintaining the system as simple as possible. Further improve the code with reconstruction after all tests. The more simple code life cycle will be long.
Extreme programming uses the collective code ownership. XP practices try to reduce the following risks brought by the collective code ownership. Personal pride: XP does not actually handle this problem, in addition to might encourage it to be proud of the team. Penalty is not criticized: the programming and 100% run unit test will help ensure that no one can conduct "pollution" privately. The professional knowledge is insufficient: the program is propagated in the team. Read other people code: The coding standard helps reduce this problem. Stepping on: Continuous integration guarantees that people will not go too far even without returning the main line, and the test will ensure that there will be no reverse.
XP uses continuous integration. Each developer has completed the work for a while, it will integrate what they do. Integration in XP is supported by test support. Developers must keep all units to test 100% operation.
For overtime, XP thinks more suitable for 40 hours a week. The XP team needs to be withstanded productivity. If the team repeatedly unable to complete your own commitment, they will return the problem, not to take overtime. The XP team follows "Yesterday's Weather" Rules: It is estimated that the time required for the next iteration is about the same as this estimated working day. This rule helps team find its normal productivity level. You can't change time, but you can change your task.
XP specifies an open work area, usually a small private space around a central area.
XP is recommended for small and frequent release. The XP team has been trying to learn, the more feedback they get. The projects that have not been released in several months or even years will accumulate a lot of risks, and the small version will reduce the risk. The version should be small, but must be construed, at least all of the features should be included.
For coding standards, the XP team must share a standard.
The above content is from the "Exploring Limit Programming" People's Posts William C. Wake Zheng Ronglin Translation is the first part of the reading note (XP programming)
