Nội dung

Extreme Programming in Perl Robert Nagler January 8, 2005 Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org Contents Preface 1 The 1.1 1.2 1.3 1.4 1.5 1.6 ix Problem Some Statistics . . . . . . . Risk Averse Methodologies Fostering Failure . . . . . . Get Me a Rock . . . . . . . Requirements Risk . . . . . Let’s Rock And Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 3 4 5 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 9 9 11 12 13 14 3 Perl 3.1 Core Values . . . . . . . . . 3.2 Customer-Orientation . . . 3.3 Testing . . . . . . . . . . . 3.4 CPAN . . . . . . . . . . . . 3.5 Organizing Your Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 18 19 19 19 2 Extreme Programming 2.1 Core Values . . . . . 2.2 Communication . . . 2.3 Simplicity . . . . . . 2.4 Feedback . . . . . . 2.5 Courage . . . . . . . 2.6 The Practices . . . . 2.7 Adopting XP . . . . . . . . . . . . . . . . . . . . . . . . . 4 Release Planning 21 4.1 Planning Game . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3 Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 iii 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 On-site Customer . Story Cards . . . . Dead Wood . . . . Estimation . . . . Easing Estimation Spike Solutions . . Prioritization . . . All the Facts . . . Small Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 24 26 28 28 29 30 31 31 5 Iteration Planning 5.1 Tasks . . . . . . . . . . 5.2 The Meeting . . . . . . 5.3 Get Me a Bucket . . . . 5.4 Velocity . . . . . . . . . 5.5 Watch Your Speed . . . 5.6 Customer Priorities . . . 5.7 Taking Care of Business 5.8 The Beat Goes on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 33 34 35 35 36 36 37 37 6 Pair Programming 6.1 Quality . . . . . . . . . . . . . . . 6.2 How It Works . . . . . . . . . . . . 6.3 Ease on down the Road . . . . . . 6.4 Rest & Relaxation . . . . . . . . . 6.5 People Problems . . . . . . . . . . 6.6 Different Strokes . . . . . . . . . . 6.7 Yea, Whatever . . . . . . . . . . . 6.8 Gumption Traps . . . . . . . . . . 6.9 Reducing Risk Through Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 40 41 41 41 43 44 44 45 7 Tracking 7.1 Iteration Tracking . . . . 7.2 Don’t Slip the Date . . . . 7.3 Adding Tasks . . . . . . . 7.4 The Tracker . . . . . . . . 7.5 Release Tracking . . . . . 7.6 What Goes Wrong? . . . 7.7 Fixing Troubled Projects 7.8 Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 48 48 49 49 50 51 54 55 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv 7.9 Show Your Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 7.10 Sign Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11 Here and Now . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Acceptance Testing 8.1 Acceptance Tests . . . . . . . . . . . . . . 8.2 Automation . . . . . . . . . . . . . . . . . 58Hfootnote.42 8.4 Group Multiple Paths . . . . . . . . . . . 8.5 Without Deviation, Testing Is Incomplete 8.6 Subject Matter Oriented Programming . . 8.7 Data-Driven Testing . . . . . . . . . . . . 8.8 Empower The Customer to Test . . . . . 9 Coding Style 9.1 There’s More Than One Way To Do It . 9.2 Give Me Consistency or Give Me Death 9.3 Team Colors . . . . . . . . . . . . . . . 9.4 An Example . . . . . . . . . . . . . . . . 9.5 You Say, “if else”, And I Say, “? :” 9.6 Once And Only Once . . . . . . . . . . 9.7 Refactored Example . . . . . . . . . . . 9.8 Change Log . . . . . . . . . . . . . . . . 9.9 Refactoring . . . . . . . . . . . . . . . . 9.10 Input Validation . . . . . . . . . . . . . 9.11 You’d Rather Die . . . . . . . . . . . . . . . . . . . . . . . . 57 . . . . . . . . . . . 57 . . . . . . . . . . . 58 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 61 63 64 66 . . . . . . . . . . . 67 68 68 69 70 72 73 73 75 78 78 79 10 Logistics 11 Test-Driven Design 11.1 Unit Tests . . . . . . . . . . . . 11.2 Test First, By Intention . . . . 11.3 Exponential Moving Average . 11.4 Test Things That Might Break 11.5 Satisfy The Test, Don’t Trick It 11.6 Test Base Cases First . . . . . 11.7 Choose Self-Evident Data . . . 11.8 Use The Algorithm, Luke! . . . 11.9 Fail Fast . . . . . . . . . . . . . 11.10Deviance Testing . . . . . . . . 55 56 56 81 . . . . . . . . . . . . . . . . . . . . Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 84 84 86 86 87 88 89 90 91 92 v 11.11Only Test The New API . . . . . . . . . . . . . . . . . . . . . 11.12Solid Foundation . . . . . . . . . . . . . . . . . . . . . . . . . 12 Continuous Design 12.1 Refactoring . . . . . . . . . . . . . . . . . . 12.2 Simple Moving Average . . . . . . . . . . . 12.3 SMA Unit Test . . . . . . . . . . . . . . . . 12.4 SMA Implementation . . . . . . . . . . . . 12.5 Move Common Features to a Base Class . . 12.6 Refactor the Unit Tests . . . . . . . . . . . 12.7 Fixing a Defect . . . . . . . . . . . . . . . . 12.8 Global Refactoring . . . . . . . . . . . . . . 12.9 Continuous Rennovation in the Real World 12.10Simplify Accessors . . . . . . . . . . . . . . 12.11Change Happens . . . . . . . . . . . . . . . 93 94 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 96 97 97 98 100 102 103 105 108 109 110 13 Unit Testing 13.1 Testing Isn’t Hard . . . . . . . . . . . . . . . 13.2 Mail::POP3Client . . . . . . . . . . . . . . . 13.3 Make Assumptions . . . . . . . . . . . . . . . 13.4 Test Data Dependent Algorithms . . . . . . . 13.5 Validate Basic Assumptions First . . . . . . . 13.6 Validate Using Implementation Knowledge . . 13.7 Distinguish Error Cases Uniquely . . . . . . . 13.8 Avoid Context Sensitive Returns . . . . . . . 13.9 Use IO::Scalar for Files . . . . . . . . . . . 13.10Perturb One Parameter per Deviance Case . 13.11Relate Results When You Need To . . . . . . 13.12Order Dependencies to Minimize Test Length 13.13Consistent APIs Ease Testing . . . . . . . . . 13.14Inject Failures . . . . . . . . . . . . . . . . . . 13.15Mock Objects . . . . . . . . . . . . . . . . . . 13.16Does It Work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 111 112 112 113 114 115 116 117 118 118 119 120 121 122 123 125 . . . . . 127 . 128 . 128 . 128 . 129 . 131 14 Refactoring 14.1 Design on Demand . . . . . . . . . 14.2 Mail::POP3Client . . . . . . . . . 14.3 Remove Unused Code . . . . . . . 14.4 Refactor Then Fix . . . . . . . . . 14.5 Consistent Names Ease Refactoring Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi 14.6 Generate Repetitive Code . . 14.7 Fix Once and Only Once . . 14.8 Stylin’ . . . . . . . . . . . . . 14.9 Tactics Versus Strategy . . . 14.10Refactor With a Partner . . . 14.11Sharing with Code References 14.12Refactoring Illuminates Fixes 14.13Brush and Floss Regularly . . . . . . . . . . 15 It’s a SMOP 15.1 The Problem . . . . . . . . . . 15.2 Planning Game . . . . . . . . . 15.3 Dividing the Story into Tasks . 15.4 Coding Style . . . . . . . . . . 15.5 Simple Design . . . . . . . . . . 15.6 Imperative versus Declarative . 15.7 Pair Programming . . . . . . . 15.8 Test First, By Intention . . . . 15.9 Statelessness . . . . . . . . . . 15.10XML::Parser . . . . . . . . . . 15.11First SMOP . . . . . . . . . . . 15.12First Interpreter . . . . . . . . 15.13Functional Programming . . . . 15.14Outside In . . . . . . . . . . . . 15.15May I, Please? . . . . . . . . . 15.16Second Task . . . . . . . . . . . 15.17Unit Test Maintenance . . . . . 15.18Second SMOP . . . . . . . . . 15.19Second SMOP Interpreter . . . 15.20Spike Solutions . . . . . . . . . 15.21Third Task . . . . . . . . . . . 15.22Third SMOP . . . . . . . . . . 15.23Third SMOP Interpreter . . . . 15.24The Metaphor . . . . . . . . . . 15.25Fourth Task . . . . . . . . . . . 15.26Fourth SMOP . . . . . . . . . . 15.27Fourth SMOP Interpreter . . . 15.28Object-Oriented Programming 15.29Success! . . . . . . . . . . . . . 15.30Virtual Pair Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 133 134 134 135 138 139 141 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 . 143 . 144 . 145 . 146 . 146 . 147 . 149 . 149 . 150 . 151 . 152 . 153 . 154 . 155 . 155 . 156 . 157 . 158 . 159 . 160 . 160 . 162 . 162 . 163 . 164 . 166 . 167 . 167 . 168 . 169 vii 15.31Open Source Development 15.32Deviance Testing . . . . . 15.33Final Implementation . . 15.34Separate Concerns . . . . 15.35 Travel Light . . . . . . . with . . . . . . . . . . . . XP . . . . . . . . . . . . . Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 171 172 177 178 viii Preface Have fun, and build something cool. – Pete Bonham This book is about a marriage of two compatible yet unlikely partners. Extreme Programming (XP) is a software development methodology that enables users, business people, programmers, and computers to communicate effectively. Perl is a dynamic programming language that lets an XP team embrace the inevitable change caused by effective communication. Perl is the fixer and doer of the pair, and XP is the organizer and facilitator. Together they help you build robust software applications efficiently. Like any good marriage, the partners of Extreme Perl support each other. For example, XP asks business people to write acceptance tests, and Perl lets the business people use their own language and tools for the tests. Much of Perl only happens when the program runs, and XP asks programmers to define what is supposed to happen in unit tests before they write the program. In this book, you’ll see other examples where Perl reinforces XP and vice versa. This mutual support system is what makes Extreme Perl applications robust. This book invites Perl programmers and their customers to take a fresh look at software development. Customers, and business people in general, will learn how XP enables customer-programmer communication for efficient and flexible requirements gathering. Programmers will see how XP’s focus on teamwork, incremental testing, and continuous design allows them to take pride in their craft. The numerous examples demonstrate Extreme Perl in action, including the development of a complete, end-to-end application in the last chapter. ix To Business People and Users XP combines your project responsibilities into a single official role: the customer. That’s the extent of the formalism. You don’t need to learn usecase modeling, object modeling, or even fashion modeling. You write your requirements on a piece of paper with pen. You even get to draw pictures, although the programmers would prefer you didn’t use crayon. As the customer, you have the responsibility to speak in one voice. You can discuss the requirements as much as you like, but in the end, you write down a simple, clear requirement in your own language, called a story. Any disagreements need to be settled during the planning game, where you and the programmers hash out what needs to get done and how long it is going to take. XP lets you change your mind. That means you have to hang around the programmers–something that may take getting used to. Programmers are terrible mind readers, and your immediate feedback is necessary when they get the requirements wrong or you realize a requirement isn’t quite right. Best of all, you get to see progress right away. The programmers do the simplest thing that could possibly work, and believe it or not, this actually produces a working program in a matter of weeks. There’s nothing better than seeing your requirements embodied in software to ensure you are getting what you want, and that you get what you are paying for. Everybody is motivated by a working product in use. To Programmers and Their Managers The programming role is quite broad in XP. Programmers are responsible for listening to the customer, and reacting to the dynamic requirements of the customer’s world. With XP, you get to be real. No more fudged estimates or wild guesses. If the customer adds a complex requirement, like internationalization, right in the middle of the project, it’s clearly not for free, and you get to say how long it will take. XP managers are coaches and trackers. The programmers do all the work, and the coach gives sage advice while sipping martinis. If all goes well, the tracker has a passive role, too. XP’s 12 simple practices add up to a lot of checks and balances. Sometimes the coach and tracker must remind the programmers how to use the practices effectively, however. Code is the core artifact of an XP project. You have to like to code to Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org x