Extreme ProgrammingTheory & XPeriences

Arie van Deursen31 October 2000

http://www.cwi.nl/~arie/

2

Software Development Risks

Schedule slips Project canceled System goes sour / high defect rate Business misunderstood / changes False feature rich Staff turnover

What are your most pressingdevelopment problems?

3

XP Project Characteristics

Use of object technology (use of modern language)

Development team size: 2 to 20 people

Developers take responsibility Participating customer

4

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 appliedto the extreme

5

Self-Testing Code

Every class also has a TestClass TestClass methods:

set up fixture invoke code to be tested Automatically check results tear down fixture

Collect test in suites; run them all.

All tests mustrun at 100%at all times

6

JUnit

http://www.junit.org

7

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

Modify the code to turn red into green bar

8

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

9

Refactoring

Refactoring 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

InteractiveTransformation

Introduce design patterns

10

Bad Smells in Code

Duplicated Code Long Method Large Class Long Parameter

List Divergent Change Shotgun Surgery

Feature Envy Speculative

Generality Inappropriate

Intimacy Comments Switch Statements Data Clumps Data Class

out of the cave into the centrally heated world of objects

Delving intoeach other’sprivate parts

Need to take someresponsibility

Say it once!

And only once!

11

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

12

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

13

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

14

Refactoring Catalog

Name Summary Motivation Mechanism Examples Simple renamings

up to majorchanges to class

structure

15

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.

16

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

Achieved by constant refactoring!

17

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

18

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

19

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 Refactor when necessary

20

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

21

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

22

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

23

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

24

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

25

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

26

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

27

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

28

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.

29

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…)

Learning to plan more systematically.

30

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

31

XP Basic Principles

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

32

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

33

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 But make sure you try!

34

Further Info

K. Beck -- eXtreme Programming eXplained

M. Fowler -- UML Distilled (2nd Ed.)

www.c2.com/wiki

www.xprogramming.com

35

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 appliedto the extreme