XPProgrammingPractic es

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.