
Extreme Programming in Perl Robert Nagler February 22, 2017 Copyright c 2004 Robert Nagler Licensed under a Creative Commons Attribution 4.0 International License [email protected] Contents Preface ix 1 The Problem 1 1.1 Some Statistics . .2 1.2 Risk Averse Methodologies . .2 1.3 Fostering Failure . .3 1.4 Get Me a Rock . .4 1.5 Requirements Risk . .5 1.6 Let's Rock And Roll . .5 2 Extreme Programming 7 2.1 Core Values . .8 2.2 Communication . .9 2.3 Simplicity . .9 2.4 Feedback . 10 2.5 Courage . 11 2.6 The Practices . 12 2.7 Adopting XP . 13 3 Perl 15 3.1 Core Values . 15 3.2 Customer-Orientation . 16 3.3 Testing . 16 3.4 CPAN . 17 3.5 Organizing Your Workshop . 17 4 Release Planning 19 4.1 Planning Game . 20 4.2 Roles . 20 4.3 Stories . 20 4.4 On-site Customer . 21 4.5 Story Cards . 21 4.6 Dead Wood . 24 4.7 Estimation . 25 iii 4.8 Easing Estimation . 26 4.9 Spike Solutions . 26 4.10 Prioritization . 27 4.11 All the Facts . 28 4.12 Small Releases . 28 5 Iteration Planning 31 5.1 Tasks . 31 5.2 The Meeting . 32 5.3 Get Me a Bucket . 33 5.4 Velocity . 33 5.5 Watch Your Speed . 34 5.6 Customer Priorities . 34 5.7 Taking Care of Business . 35 5.8 The Beat Goes on . 35 6 Pair Programming 37 6.1 Quality . 37 6.2 How It Works . 38 6.3 Ease on down the Road . 38 6.4 Rest & Relaxation . 39 6.5 People Problems . 39 6.6 Different Strokes . 40 6.7 Yea, Whatever . 42 6.8 Gumption Traps . 42 6.9 Reducing Risk Through Knowledge Transfer . 43 7 Tracking 45 7.1 Iteration Tracking . 46 7.2 Don't Slip the Date . 46 7.3 Adding Tasks . 47 7.4 The Tracker . 47 7.5 Release Tracking . 47 7.6 What Goes Wrong? . 49 7.7 Fixing Troubled Projects . 51 7.8 Meetings . 52 7.9 Show Your Stuff . 52 7.10 Sign Off . 52 7.11 Here and Now . 53 8 Acceptance Testing 55 8.1 Acceptance Tests . 55 8.2 Automation . 56 56section.8.3 Copyright c 2004 Robert Nagler iv [email protected] 8.4 Group Multiple Paths . 58 8.5 Without Deviation, Testing Is Incomplete . 59 8.6 Subject Matter Oriented Programming . 60 8.7 Data-Driven Testing . 61 8.8 Empower The Customer to Test . 64 9 Coding Style 65 9.1 There's More Than One Way To Do It . 66 9.2 Give Me Consistency or Give Me Death . 66 9.3 Team Colors . 67 9.4 An Example . 67 9.5 You Say, \if else", And I Say, \?:"............ 70 9.6 Once And Only Once . 70 9.7 Refactored Example . 71 9.8 Change Log . 73 9.9 Refactoring . 75 9.10 Input Validation . 75 9.11 You'd Rather Die . 76 10 Logistics 79 11 Test-Driven Design 81 11.1 Unit Tests . 82 11.2 Test First, By Intention . 82 11.3 Exponential Moving Average . 84 11.4 Test Things That Might Break . 84 11.5 Satisfy The Test, Don't Trick It . 85 11.6 Test Base Cases First . 86 11.7 Choose Self-Evident Data . 87 11.8 Use The Algorithm, Luke! . 87 11.9 Fail Fast . 88 11.10Deviance Testing . 89 11.11Only Test The New API . 90 11.12Solid Foundation . 91 12 Continuous Design 93 12.1 Refactoring . 94 12.2 Simple Moving Average . 94 12.3 SMA Unit Test . 95 12.4 SMA Implementation . 96 12.5 Move Common Features to a Base Class . 98 12.6 Refactor the Unit Tests . 99 12.7 Fixing a Defect . 100 12.8 Global Refactoring . 102 Copyright c 2004 Robert Nagler v [email protected] 12.9 Continuous Rennovation in the Real World . 104 12.10Simplify Accessors . 105 12.11Change Happens . 106 13 Unit Testing 107 13.1 Testing Isn't Hard . 107 13.2 Mail::POP3Client ........................ 108 13.3 Make Assumptions . 108 13.4 Test Data Dependent Algorithms . 109 13.5 Validate Basic Assumptions First . 110 13.6 Validate Using Implementation Knowledge . 110 13.7 Distinguish Error Cases Uniquely . 112 13.8 Avoid Context Sensitive Returns . 113 13.9 Use IO::Scalar for Files . 113 13.10Perturb One Parameter per Deviance Case . 114 13.11Relate Results When You Need To . 114 13.12Order Dependencies to Minimize Test Length . 115 13.13Consistent APIs Ease Testing . 116 13.14Inject Failures . 117 13.15Mock Objects . 118 13.16Does It Work? . 119 14 Refactoring 121 14.1 Design on Demand . 122 14.2 Mail::POP3Client ........................ 122 14.3 Remove Unused Code . 122 14.4 Refactor Then Fix . 123 14.5 Consistent Names Ease Refactoring . 125 14.6 Generate Repetitive Code . 126 14.7 Fix Once and Only Once . 126 14.8 Stylin' . 127 14.9 Tactics Versus Strategy . 127 14.10Refactor With a Partner . 128 14.11Sharing with Code References . 131 14.12Refactoring Illuminates Fixes . 132 14.13Brush and Floss Regularly . 133 15.
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages182 Page
-
File Size-