2. 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

3. Extreme Programming (XP) At its core, XP is:

4. Extreme Programming (XP) At its core, XP is: Very Short Cycles

5. Extreme Programming (XP) At its core, XP is: Very Short Cycles Intense Feedback

6. Extreme Programming (XP) At its core, XP is: Very Short Cycles Intense Feedback Networked Communication

7. The XP Planning Practices User Stories

8. The XP Planning Practices User Stories Release Planning

9. The XP Planning Practices User Stories Release Planning Iteration Planning

10. The XP Planning Practices User Stories Release Planning Iteration Planning On Site Customer

11. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

12. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

13. Pair Programming Two Programmers sit at one workstation

14. Pair Programming Two Programmers sit at one workstation They take turns “driving”

15. Pair Programming Two Programmers sit at one workstation They take turns “driving” Pairs are short lived

16. Pair Programming Two Programmers sit at one workstation They take turns “driving” Pairs are short lived Pairing transmits knowledge to the team

17. 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

18. Pairing keeps the pace When programming alone, you sometimes find yourself working at super speed.

19. 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.

20. 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.

21. 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.

22. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

23. Test First Design In Tiny (5 min) cycles

24. Test First Design In Tiny (5 min) cycles Write a test case.

25. Test First Design In Tiny (5 min) cycles Write a test case. Write the code that passes it.

26. 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.

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

28. 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 { }

29. 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 { }

30. This may seem useless.

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

32. 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.

33. 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.

34. 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); }

35. 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;} }

36. Test First Example

37. XUNIT Lightweight Unit Testing Framework www.junit.org Junit Cppunit Pyunit Etc.

38. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

39. Refactoring After getting something to work we refactor.

40. Refactoring After getting something to work we refactor. Tiny (5 min) improvements

41. Refactoring After getting something to work we refactor. Tiny (5 min) improvements Followed by running all the tests.

42. 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.

43. Refactoring We cannot check in our code until:

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

45. Refactoring We cannot check in our code until: All tests are green. All duplication has been removed

46. 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.

47. 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.

48. Refactoring Comments should be minimized

49. Refactoring Comments should be minimized They often lie.

50. Refactoring Comments should be minimized They often lie. They are an admission that we could not make our code express our ideas.

51. 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.

52. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

53. Continuous Integration Daily builds are for wimps.

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

55. Continuous Integration Daily builds are for wimps. Build, end to end, at every check in. Check in frequently.

56. Continuous Integration Daily builds are for wimps. Build, end to end, at every check in. Check in frequently. Put resources on speeding build time.

57. 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.

58. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

59. Collective Ownership Anyone can improve any part of the code at any time.

60. 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.

61. 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…

62. 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…

63. 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

64. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

65. Coding Standard A group of conventions that everyone agrees to.

66. Coding Standard A group of conventions that everyone agrees to. Emerges over time.

67. Coding Standard A group of conventions that everyone agrees to. Emerges over time. Continuously evolves.

68. Coding Standard A group of conventions that everyone agrees to. Emerges over time. Continuously evolves. The team rules.

69. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

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

71. 40 hour week You can’t do your best when you are tired. When you don’t do your best, you make messes.

72. 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

73. 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.

74. 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.

75. XP Programming Practices Pair Programming Test-first Design Refactoring Continuous Integration Collective Ownership Coding Standard 40 hour week

76. The End.