Extreme programming: Difference between revisions

Revision as of 12:01, 18 October 2001

Revision as of 22:25, 1 January 2002

Line 1:

Extreme programming, or "XP" takes certain simple practices that are known to improve software quality. Then, it takes these to logical extremes.

Extreme Programming (XP) is a new [[method]] in or approach to [[software engineering]], formulated by [[Kent Beck]], who wrote the first book on the topic, "Extreme Programming Explained. Embrace Change" (ISBN 0201616416).

1. Requirements are addressed by having a customer on-site, available to the programmers. If this is not possible, the customer may describe use cases on cards, that are periodically photocopied for the engineering staff.

For more information on this and related topics, see the definition at [[Ward Cunningham]]'s website, http://www.c2.com/cgi/wiki?ExtremeProgramming

2. Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs in the present project.

Fundamental for the method are:

*short incremental [[programming]] steps

*continuous, often repeated automated regression testing. See [[JUnit]].

3. Code reviews are good. Therefore XP has programmers program in pairs, sharing one screen and keyboard.

*[[pair programming]]

*user interaction in the programming team

*fixing all known [[bug|bugs]] before adding functionality

4. Testing code is good. Therefore, in XP, test suites are written before the code is written. The code is considered complete when it passes the tests. The system is periodically, or immediately tested using all preexisting automated tests to assure that it works.

*[[refactoring]]

----

/Talk