extreme programming programming practices object mentor, inc. copyright 1998-2000 by object mentor,...

Extreme ProgrammingProgramming Practices

Object Mentor, Inc.

Copyright 1998-2000 by Object Mentor, IncAll Rights Reserved

Portions of this material are Copyright © 2000, by Addison Wesley Longman,Inc. and have been

reproduced here with permission.

www.objectmentor.com

Extreme Programming (XP)

At its core, XP is:

Extreme Programming (XP)

At its core, XP is:Very Short Cycles

Extreme Programming (XP)

At its core, XP is:Very Short Cycles

Intense Feedback

Extreme Programming (XP)

At its core, XP is:Very Short Cycles

Intense Feedback

Networked Communication

The XP Planning Practices

User Stories

The XP Planning Practices

User Stories

Release Planning

The XP Planning Practices

User Stories

Release Planning

Iteration Planning

The XP Planning Practices

User Stories

Release Planning

Iteration Planning

On Site Customer

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

Pair Programming

Two Programmers sit at one workstation

Pair Programming

Two Programmers sit at one workstation

They take turns “driving”

Pair Programming

Two Programmers sit at one workstation

They take turns “driving”

Pairs are short lived

Pair Programming

Two Programmers sit at one workstation

They take turns “driving”

Pairs are short lived

Pairing transmits knowledge to the team

Pair Programming

Two Programmers sit at one workstation

They take turns “driving”

Pairs are short lived

Pairing transmits knowledge to the team

Pairing train newbies

Pairing keeps the pace

When programming alone, you sometimes find yourself working at super speed.

Pairing keeps the pace

When programming alone, you sometimes find yourself working at super speed.

After awhile, you lose focus and drift away in the afterglow.

Pairing keeps the pace

When programming alone, you sometimes find yourself working at super speed.

After awhile, you lose focus and drift away in the afterglow.

Your partner keeps both from happening.

Pair Programming Research

Laurie Williams, http://collaboration.csc.ncsu.edu/laurie/

Findings:Pairs use no more manhours than singles.

Pairs create fewer defects.

Pairs create fewer lines of code.

Pairs enjoy their work more.

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

Test First Design

In Tiny (5 min) cycles

Test First Design

In Tiny (5 min) cyclesWrite a test case.

Test First Design

In Tiny (5 min) cyclesWrite a test case.

Write the code that passes it.

Test First Design

In Tiny (5 min) cyclesWrite a test case.

Write the code that passes it.

Repeat until program does what you want.

Test First Example

import junit.framework.*;public class TestAutoMileageLog extends TestCase{ public TestAutoMileageLog(String name) { super(name); } public void testCreateFuelingStationVisit() { FuelingStationVisit v = new FuelingStationVisit(); }}

Test First Example

import junit.framework.*;public class TestAutoMileageLog extends TestCase{ public TestAutoMileageLog(String name) { super(name); } public void testCreateFuelingStationVisit() { FuelingStationVisit v = new FuelingStationVisit(); }}

public class FuelingStationVisit{}

Test First Example

import junit.framework.*;public class TestAutoMileageLog extends TestCase{ public TestAutoMileageLog(String name) { super(name); } public void testCreateFuelingStationVisit() { FuelingStationVisit v = new FuelingStationVisit(); }}

public class FuelingStationVisit{}

This may seem useless.

This may seem useless.

But it shows me that the test framework is functioning properly.

This may seem useless.

But it shows me that the test framework is functioning properly.

It also gives me a working base to continue from.

This may seem useless.

But it shows me that the test framework is functioning properly.

It also gives me a working base to continue from.

We move, in tiny steps, from working base, to working base.

Test First Example

public void testCreateFuelingStationVisit() { Date date = new Date(); double fuel = 2.0; // 2 gallons. double cost = 1.87*2; // Price = $1.87 per gallon int mileage = 1000; // odometer reading. double delta = 0.0001; //fp tolerance FuelingStationVisit v = new FuelingStationVisit( date, fuel, cost, mileage); assertEquals(date, v.getDate()); assertEquals(1.87*2, v.getCost(), delta); assertEquals(2, v.getFuel(), delta); assertEquals(1000, v.getMileage()); assertEquals(1.87, v.getPrice(), delta); }

Test First Example

public class FuelingStationVisit { public FuelingStationVisit(Date date, double fuel, double cost, int mileage) { itsDate = date; itsFuel = fuel; itsCost = cost; itsMileage = mileage; } public Date getDate() {return itsDate;} public double getFuel() {return itsFuel;} public double getCost() {return itsCost;} public double getPrice() {return itsCost/itsFuel;} public int getMileage() {return itsMileage;}}

Test First Example

XUNIT

Lightweight Unit Testing Frameworkwww.junit.org

Junit

Cppunit

Pyunit

Etc.

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

Refactoring

After getting something to work we refactor.

Refactoring

After getting something to work we refactor.

Tiny (5 min) improvements

Refactoring

After getting something to work we refactor.

Tiny (5 min) improvements

Followed by running all the tests.

Refactoring

After getting something to work we refactor.

Tiny (5 min) improvements

Followed by running all the tests.

Build and test time must be very very fast.

Refactoring

We cannot check in our code until:

Refactoring

We cannot check in our code until:All tests are green.

Refactoring

We cannot check in our code until:All tests are green.

All duplication has been removed

Refactoring

We cannot check in our code until:All tests are green.

All duplication has been removed

The code is as expressive as we can make it.

Refactoring

We cannot check in our code until:All tests are green.

All duplication has been removed

The code is as expressive as we can make it.

The code is as simple as we can make it.

Refactoring

Comments should be minimized

Refactoring

Comments should be minimizedThey often lie.

Refactoring

Comments should be minimizedThey often lie.

They are an admission that we could not make our code express our ideas.

Refactoring

Comments should be minimizedThey often lie.

They are an admission that we could not make our code express our ideas.

There are many things you can do to make software more expressive.

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

Continuous Integration

Daily builds are for wimps.

Continuous Integration

Daily builds are for wimps.Build, end to end, at every check in.

Continuous Integration

Daily builds are for wimps.Build, end to end, at every check in.

Check in frequently.

Continuous Integration

Daily builds are for wimps.Build, end to end, at every check in.

Check in frequently.

Put resources on speeding build time.

Continuous Integration

Daily builds are for wimps.Build, end to end, at every check in.

Check in frequently.

Put resources on speeding build time.

Put resources on speeding test time.

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

Collective Ownership

Anyone can improve any part of the code at any time.

Collective Ownership

Anyone can improve any part of the code at any time.

No one acts as the gatekeeper for any part of the code.

Collective Ownership

Anyone can improve any part of the code at any time.

No one acts as the gatekeeper for any part of the code.

This includes schemas…

Collective Ownership

Anyone can improve any part of the code at any time.

No one acts as the gatekeeper for any part of the code.

This includes schemas…

And libraries…

Collective Ownership

Anyone can improve any part of the code at any time.

No one acts as the gatekeeper for any part of the code.

This includes schemas…

And libraries…

And everything else that’s different

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

Coding Standard

A group of conventions that everyone agrees to.

Coding Standard

A group of conventions that everyone agrees to.

Emerges over time.

Coding Standard

A group of conventions that everyone agrees to.

Emerges over time.

Continuously evolves.

Coding Standard

A group of conventions that everyone agrees to.

Emerges over time.

Continuously evolves.

The team rules.

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

40 hour week

You can’t do your best when you are tired.

40 hour week

You can’t do your best when you are tired.

When you don’t do your best, you make messes.

40 hour week

You can’t do your best when you are tired.

When you don’t do your best, you make messes.

Messes slow everyone down

40 hour week

You can’t do your best when you are tired.

When you don’t do your best, you make messes.

Messes slow everyone down

So you must be rested.

40 hour week

You can’t do your best when you are tired.

When you don’t do your best, you make messes.

Messes slow everyone down

So you must be rested

Occasionally, you may work one week of moderate overtime.

XP Programming Practices

Pair Programming

Test-first Design

Refactoring

Continuous Integration

Collective Ownership

Coding Standard

40 hour week

The End.