Presentation Transcript
Extreme ProgrammingProgramming Practices : Extreme Programming Programming Practices Object Mentor, Inc. Copyright 1998-2000 by Object Mentor, Inc
All 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) : Extreme Programming (XP) At its core, XP is:
Extreme Programming (XP) : Extreme Programming (XP) At its core, XP is:
Very Short Cycles
Extreme Programming (XP) : Extreme Programming (XP) At its core, XP is:
Very Short Cycles
Intense Feedback
Extreme Programming (XP) : Extreme Programming (XP) At its core, XP is:
Very Short Cycles
Intense Feedback
Networked Communication
The XP Planning Practices : The XP Planning Practices User Stories
The XP Planning Practices : The XP Planning Practices User Stories
Release Planning
The XP Planning Practices : The XP Planning Practices User Stories
Release Planning
Iteration Planning
The XP Planning Practices : The XP Planning Practices User Stories
Release Planning
Iteration Planning
On Site Customer
XP Programming Practices : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
XP Programming Practices : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
Pair Programming : Pair Programming Two Programmers sit at one workstation
Pair Programming : Pair Programming Two Programmers sit at one workstation
They take turns “driving”
Pair Programming : Pair Programming Two Programmers sit at one workstation
They take turns “driving”
Pairs are short lived
Pair Programming : Pair Programming Two Programmers sit at one workstation
They take turns “driving”
Pairs are short lived
Pairing transmits knowledge to the team
Pair Programming : 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 : Pairing keeps the pace When programming alone, you sometimes find yourself working at super speed.
Pairing keeps the pace : 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 : 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 : 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 : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
Test First Design : Test First Design In Tiny (5 min) cycles
Test First Design : Test First Design In Tiny (5 min) cycles
Write a test case.
Test First Design : Test First Design In Tiny (5 min) cycles
Write a test case.
Write the code that passes it.
Test First Design : Test First Design In Tiny (5 min) cycles
Write a test case.
Write the code that passes it.
Repeat until program does what you want.
Test First Example : 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 : 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 : 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.
This may seem useless. : This may seem useless. But it shows me that the test framework is functioning properly.
This may seem useless. : 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. : 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 : 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 : 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 : Test First Example
XUNIT : XUNIT Lightweight Unit Testing Framework
www.junit.org
Junit
Cppunit
Pyunit
Etc.
XP Programming Practices : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
Refactoring : Refactoring After getting something to work we refactor.
Refactoring : Refactoring After getting something to work we refactor.
Tiny (5 min) improvements
Refactoring : Refactoring After getting something to work we refactor.
Tiny (5 min) improvements
Followed by running all the tests.
Refactoring : 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 : Refactoring We cannot check in our code until:
Refactoring : Refactoring We cannot check in our code until:
All tests are green.
Refactoring : Refactoring We cannot check in our code until:
All tests are green.
All duplication has been removed
Refactoring : 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 : 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 : Refactoring Comments should be minimized
Refactoring : Refactoring Comments should be minimized
They often lie.
Refactoring : Refactoring Comments should be minimized
They often lie.
They are an admission that we could not make our code express our ideas.
Refactoring : Refactoring Comments should be minimized
They 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 : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
Continuous Integration : Continuous Integration Daily builds are for wimps.
Continuous Integration : Continuous Integration Daily builds are for wimps.
Build, end to end, at every check in.
Continuous Integration : Continuous Integration Daily builds are for wimps.
Build, end to end, at every check in.
Check in frequently.
Continuous Integration : 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 : 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 : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
Collective Ownership : Collective Ownership Anyone can improve any part of the code at any time.
Collective Ownership : 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 : 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 : 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 : 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 : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
Coding Standard : Coding Standard A group of conventions that everyone agrees to.
Coding Standard : Coding Standard A group of conventions that everyone agrees to.
Emerges over time.
Coding Standard : Coding Standard A group of conventions that everyone agrees to.
Emerges over time.
Continuously evolves.
Coding Standard : Coding Standard A group of conventions that everyone agrees to.
Emerges over time.
Continuously evolves.
The team rules.
XP Programming Practices : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
40 hour week : 40 hour week You can’t do your best when you are tired.
40 hour week : 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 : 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 : 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 : 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 : XP Programming Practices Pair Programming
Test-first Design
Refactoring
Continuous Integration
Collective Ownership
Coding Standard
40 hour week
The End. : The End.
Catch the
buzz on authorSTREAM
Copyright © 2002-2008 authorSTREAM. All rights reserved.