Transcript Het Jaar 2000 Probleem - Delft University of Technology

Extreme Programming
Theory & XPeriences
Arie van Deursen
31 October 2000
http://www.cwi.nl/~arie/
Software Development
Risks
What are your most pressing
development problems?
Schedule slips
 Project canceled
 System goes sour / high defect rate
 Business misunderstood / changes
 False feature rich
 Staff turnover

2
XP Project Characteristics

Use of object technology
(use of modern language)

Development team size:
 2 to 20 people
Developers take responsibility
 Participating customer

3
XP Practices

The Planning Game
Small Releases
 Metaphor




Simple design
Testing
Refactoring

Pair programming

Collective ownership
Continuous integration
40-hour week
On-site customer
Coding standards




all applied
to the extreme
4
Self-Testing Code
Every class also has a TestClass
 TestClass methods:

 set up fixture
 invoke code to be tested
All tests must
run at 100%
at all times
 Automatically check results
 tear down fixture

5
Collect test in suites; run them all.
JUnit
http://www.junit.org
6
Test First
Run all tests and get green bar;
 Write (failing) test before coding:

 if interface is unclear
 if implementation might be hard
 for every special case (if-then-else)
 before dealing with bug report

7
Modify the code to turn red into green bar
Our Testing XPeriences
Test / production code ratio of 1:2
 Writing tests forced us to write smaller
methods
 Test case = documentation
 Having many test cases helps to dare
change other people’s code.
 Systematic reuse of each other’s tests

8
Refactoring

Interactive
Transformation
Refactoring
Introduce
design patterns
A change made
 to the internal structure of software
 to make it easier to understand
 and cheaper to modify
 without changing its observable behavior

Refactor:
 apply series of refactorings
9
Bad Smells
in Code






Duplicated Code
Long Method
Large Class
Long Parameter List
Divergent Change
Shotgun Surgery
Say it once!
And only once!






Need to take some
responsibility
10

Feature Envy
Speculative Generality
Inappropriate Delving into
Intimacy
each other’s
private parts
Comments
Switch Statements
Data Clumps
Data Class
out of the cave into the centrally
heated world of objects
Why Refactor?
Improves the Design of Software
 Makes software easier to understand

 Refactor first to understand unfamiliar code
 Small refactoring -> larger ones
 “Wiping the dirt off a window, so you can see
beyond”
Helps you find bugs
 Helps you program faster

11
When should you Refactor?

Three strikes and you refactor
 First time: just do it.
 Second time something similar: duplicate
 Third time something similar: refactor.
Add feature
 Fix bug
 Review Code

12
Refactoring Process

Modifying code involves:
 Test (add if necessary)
 Refactor to increase understanding
 Test
 Add tests for change, modify until it passes;
 Test
 Refactor to bring code to simplest state
 Test
13
Refactoring Catalog
Name
 Summary
 Motivation
 Mechanism
 Examples

14
Simple renamings
up to major
changes to class
structure
Refactoring XPeriences

Software improvement is explicit part of
programming activity

Possible thanks to test suites

Small refactorings on a daily basis

Large refactorings applied incrementally.
15
Simplicity

XP: Have the simplest design that runs
the current test suite:
 Code + tests communicate everything you
want to communicate
 The system contains no duplicate code
 The system has the fewest possible classes
 The system has the fewest possible methods

16
Achieved by constant refactoring!
Design Through
Refactoring
Each change includes refactoring
 Each refactoring improves/repairs the
design
 Large refactorings done by need
 Each refactoring = mini design-phase

 => Death of the big design (phase)
 => No separation programmer/architect
17
Design for Tomorrow
Guess at the future.
 Tomorrow may never happen
 Learn a better way to implement a change
before the time you need it
 Pay cost of carrying along a more
complicated design
 Costs of unused generalizations > benefits
of used generalizations

18
Design for Today

Trust your ability to change
 Rely on tests
 Implement changes together
 Use modern programming technology
 Remove any flexibility that isn’t useful

Design test by test: Repeatedly
 Write a test -> implies bit of design;
 Design & implement its code
19
 Refactor when necessary
Our Design XPeriences
Designs evolve
 Re-design = refactoring
 Small refactorings done every day
 Major refactorings:

 Senior programmers involved
 Discussed with complete team
 Exploration first
 Implemented incrementally
20
Pair Programming

All production code is written with two
people looking at one machine, with one
keyboard and one mouse.

If code review is good, we do it all the
time
21
Pair Programming
XPeriences
(Initial) resistance
 Changing pairs
 Discuss design, refactorings, tests
 Way to communicate system knowledge
 Improves quality (a lot)
 Coding is more fun, calmer, and less solitary
 More (> 2) productive

22
User Stories

Collect requirements as user stories
 Possible to explain, test, and estimate
Prioritize stories in order of business
importance
 Development:

 Estimate effort for stories
 Highlight technical risks / consequences
23
Growing a System
Have a running system from day 1.
 Integrate stories one by one
 Work with small iterations:

 Approx. 3 weeks
 Split (combine) stories into tasks, estimate
 Design, test, build, test
 Measure progress, learn to estimate
24
Planning a Release

Release: every 2 - 6 months
 Fix date, cost and quality
 Determine scope: how many stories can be
done following development estimates
 Most important user stories first

Feedback / adjustment at every iteration
 New / modified stories
 Changed estimates
25
The Planning Game

XP Planning:
 Dialog between possible and desirable
 Set of rules to govern building respectful
relationship
 Metaphor: Game

The Goal:
 Maximize value of software produced by the
team
26
Planning Game (cont.)

The Strategy:
 Put the most valuable functionality
 into production as quickly as possible
 with minimal initial investment
 addressing risk first

The Pieces:
 Cards containing user stories
27
Planning Game (cont.)

The Players:
 Business: decides what system must do
 Development: build the system

The Moves:
 Exploration: what could system do?
 Commitment:decide on this release
 Steer: Guide actual development, adjust.
28
Our Planning XPeriences

Planning internal product development
 Mimicked customer, “invented” stories
 Work in small iterations
 Always have a running system

Planning customer development
 Made planning process “XP-like”
 Didn’t force customer into XP game (yet…)

29
Learning to plan more systematically.
XP Values

Communication
 Adopt practices that encourage talking & listening

Simplicity
 What is the simplest thing that could possibly work?

Feedback
 The system tests will tell you; Listen to the code!

Courage
 Go at top speed
30
XP Basic Principles





31
Rapid feedback
Assume simplicity
Incremental
change
Embracing change
Quality work
Teach learning
 Small initial investment
 Play to win
 Concrete experiments
 Open, honest communication
 Work with instincts
 Accepted responsibility
 Local adaptation
 Travel light
 Honest measurement

XP Roles
Programmer -- pairing, testing, coding,
designing, estimating -- courageous.
 Customer -- provide user stories + tests
 Tester
-- implement functional tests
 Tracker
-- log progress
 Coach
-- teach to learn
 Consultant -- optional specialist
 Big Boss
-- confident

32
Adopting XP
Have motivated team
 Learn practices one by one
 Deceivingly simple

 tests, refactoring, pairing, planning

Take sufficient time to learn
 Course (spread over year), mentoring

33
But make sure you try!
Further Info

K. Beck -- eXtreme
Programming
eXplained

M. Fowler -- UML
Distilled (2nd Ed.)

www.c2.com/wiki

www.xprogramming.com
34
Summary: XP Practices

The Planning Game
Small Releases
 Metaphor




Simple design
Testing
Refactoring

Pair programming

Collective ownership
Continuous integration
40-hour week
On-site customer
Coding standards




all applied
to the extreme
35