extreme programming programming practices object mentor, inc. copyright 1998-2000 by object mentor,...
TRANSCRIPT
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.