eXtreme programming

pair programming

is about establishing the Flow

all code written by two persons working together on the same task on the same workstation

driver-navigator

is done by peers

pair persons one level apart

have the person with least knowledge do most of the driving

tutoring is not pair programming

change role frequently and regularly

pair promiscuously

test-driven development

test after

test during

test first

red green refactor

• write a failing unit test
• make sure it fails for the right reasons
• make the test pass
• refactor
• repeat

done is when no more tests can be written

continuous integration

check-in often

work on latest code

merge with upstream often

support downstream

refactoring

code decays

a.k.a. technical debt

duplicated code

or any kind of duplication

coding standards not followed

insufficient automated tests

complex code

hidden bugs

dead code

misleading comments

rigid design and architecture

there is a cure refactoring

restructure the code without affecting behaviour

bugfixing is not refactoring

rewriting is not refactoring

improves quality attributes

take baby steps

unit tests are a safety net

coding standards

agreed set of rules

formatting

constructs

patterns

everyone follows

code should be self-documenting

collective code ownership

everyone responsible

everyone can change

pairing helps

unit tests help

speed of development increases

simple design

simple is best

is there a simpler way?

refactoring helps

sustainable pace

no overtime

no crunchtime

a rested brain is a creative brain

xp is intensive

xp raises quality

xp is fun