This chapter is from the book
This chapter is from the book
This chapter is from the book
Programmer
XP is unusual as methodologies go, in that it prescribes activities at the day-by-day (and even at the minute-by-minute) level. We can think of XP's programming activities as shown in FIGURE 9.1.
){kind=link}
The triangle in the middle of FIGURE 9.1 captures the idea of test-first programming, a key feature of XP:
Test, then code, then refactor
This is the opposite of traditional programming, which does
Design, then code, then test
FIGURE 9.1 XP Programming Activities
In traditional programming, the cycle might take weeks to months; in XP, the cycle happens on the order of minutes to hours.
Let's look at the activities one at a time.
Stand Up Meeting at 9 AM
Meet for 10 minutes at the beginning of the day.
Identify problems and who will solve them, but don't try to solve them in the meeting.
Fix the starting time; this helps remind the team to work a 40-hour week.
Pair Up and Do a Quick Design
All production code is produced by a pair.
The typist thinks tactically, the partner thinks strategically.
Switch roles periodically.
Test
Write only small bits of unit-test code at a time.
Verify that the test fails before coding. (It's sure interesting if it doesn't fail.)
"Test everything that could possibly break."
Ask the customer if you're not sure what the answer should be.
Code
Implement just enough to make the tests pass. ("Do the Simplest Thing That Could Possibly Work.")
Follow the team's coding standard.
Refactor
Seek out "code smells" (places that don't feel right); apply a refactoring; verify that the unit tests still pass.
The code should:
Run all unit tests
Communicate what it needs to communicate
Have no duplicate logic
Have as few classes and methods as possible
Take small steps, and unit-test after each.
See Refactoring (Fowler et al., 1999).
Q&A
The customer is available on-site to provide immediate answers.
Many questions require decisions (not facts), and the customer should be prepared to make them.
The customer should write an acceptance test or (more rarely) a story to capture the answer.
Integrate or Toss
Move the code to the integration machine, build the system, and run all tests.
Fix things to bring the unit tests back to 100 percent.
Some teams require that acceptance tests be in no worse condition. (No test that was passing before you got there should be failing now.)
If you can't easily integrate, throw it away and try again tomorrow.
Return to "Pair Up"
If you have time left in the day, you can pair up (or at least switch roles) and start over on another task (perhaps the partner's).
Go Home at 5 PM
Going home on time reinforces the practice of having a 40-hour week.
Notice that nothing is hanging over your head: everything you've done for the day is integrated or tossed.
Summary
These activities remind you of important aspects of XP:
Always have a partner.
Get answers before you code.
Program test-first.
Throw it away when you need to.
Go home "clean."