Extreme Programming in Perl

Extreme Programming In Perl-Free PDF

  • Date:20 Jun 2020
  • Views:60
  • Downloads:0
  • Pages:194
  • Size:1.60 MB

Share Pdf : Extreme Programming In Perl

Download and Preview : Extreme Programming In Perl


Report CopyRight/DMCA Form For : Extreme Programming In Perl


Transcription:

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 6,2 Extreme Programming 7,2 1 Core Values 8. 2 2 Communication 9,2 3 Simplicity 9,2 4 Feedback 11. 2 5 Courage 12,2 6 The Practices 13,2 7 Adopting XP 14.
3 1 Core Values 17,3 2 Customer Orientation 18,3 3 Testing 19. 3 4 CPAN 19,3 5 Organizing Your Workshop 19,4 Release Planning 21. 4 1 Planning Game 22,4 2 Roles 22,4 3 Stories 23,4 4 On site Customer 23. 4 5 Story Cards 24,4 6 Dead Wood 26,4 7 Estimation 28. 4 8 Easing Estimation 28,4 9 Spike Solutions 29,4 10 Prioritization 30.
4 11 All the Facts 31,4 12 Small Releases 31,5 Iteration Planning 33. 5 1 Tasks 33,5 2 The Meeting 34,5 3 Get Me a Bucket 35. 5 4 Velocity 35,5 5 Watch Your Speed 36,5 6 Customer Priorities 36. 5 7 Taking Care of Business 37,5 8 The Beat Goes on 37. 6 Pair Programming 39,6 1 Quality 39,6 2 How It Works 40.
6 3 Ease on down the Road 41,6 4 Rest Relaxation 41. 6 5 People Problems 41,6 6 Different Strokes 43,6 7 Yea Whatever 44. 6 8 Gumption Traps 44,6 9 Reducing Risk Through Knowledge Transfer 45. 7 Tracking 47,7 1 Iteration Tracking 48,7 2 Don t Slip the Date 48. 7 3 Adding Tasks 49,7 4 The Tracker 49,7 5 Release Tracking 50.
7 6 What Goes Wrong 51,7 7 Fixing Troubled Projects 54. 7 8 Meetings 55,c 2004 Robert Nagler iv,nagler extremeperl org. 7 9 Show Your Stuff 55,7 10 Sign Off 56,7 11 Here and Now 56. 8 Acceptance Testing 57,8 1 Acceptance Tests 57,8 2 Automation 58. 58section 8 3,8 4 Group Multiple Paths 60,8 5 Without Deviation Testing Is Incomplete 61.
8 6 Subject Matter Oriented Programming 63,8 7 Data Driven Testing 64. 8 8 Empower The Customer to Test 66,9 Coding Style 67. 9 1 There s More Than One Way To Do It 68,9 2 Give Me Consistency or Give Me Death 68. 9 3 Team Colors 69,9 4 An Example 70,9 5 You Say if else And I Say 72. 9 6 Once And Only Once 73,9 7 Refactored Example 73.
9 8 Change Log 75,9 9 Refactoring 78,9 10 Input Validation 78. 9 11 You d Rather Die 79,10 Logistics 81,11 Test Driven Design 83. 11 1 Unit Tests 84,11 2 Test First By Intention 84. 11 3 Exponential Moving Average 86,11 4 Test Things That Might Break 86. 11 5 Satisfy The Test Don t Trick It 87,11 6 Test Base Cases First 88.
11 7 Choose Self Evident Data 89,11 8 Use The Algorithm Luke 90. 11 9 Fail Fast 91,11 10Deviance Testing 92,c 2004 Robert Nagler v. nagler extremeperl org,11 11Only Test The New API 93. 11 12Solid Foundation 94,12 Continuous Design 95,12 1 Refactoring 96. 12 2 Simple Moving Average 97,12 3 SMA Unit Test 97.
12 4 SMA Implementation 98,12 5 Move Common Features to a Base Class 100. 12 6 Refactor the Unit Tests 102,12 7 Fixing a Defect 103. 12 8 Global Refactoring 105,12 9 Continuous Rennovation in the Real World 108. 12 10Simplify Accessors 109,12 11Change Happens 110. 13 Unit Testing 111,13 1 Testing Isn t Hard 111,13 2 Mail POP3Client 112.
13 3 Make Assumptions 112,13 4 Test Data Dependent Algorithms 113. 13 5 Validate Basic Assumptions First 114,13 6 Validate Using Implementation Knowledge 115. 13 7 Distinguish Error Cases Uniquely 116,13 8 Avoid Context Sensitive Returns 117. 13 9 Use IO Scalar for Files 118,13 10Perturb One Parameter per Deviance Case 118. 13 11Relate Results When You Need To 119, 13 12Order Dependencies to Minimize Test Length 120.
13 13Consistent APIs Ease Testing 121,13 14Inject Failures 122. 13 15Mock Objects 123,13 16Does It Work 125,14 Refactoring 127. 14 1 Design on Demand 128,14 2 Mail POP3Client 128. 14 3 Remove Unused Code 128,14 4 Refactor Then Fix 129. 14 5 Consistent Names Ease Refactoring 131,c 2004 Robert Nagler vi.
nagler extremeperl org,14 6 Generate Repetitive Code 132. 14 7 Fix Once and Only Once 133,14 8 Stylin 134,14 9 Tactics Versus Strategy 134. 14 10Refactor With a Partner 135,14 11Sharing with Code References 138. 14 12Refactoring Illuminates Fixes 139,14 13Brush and Floss Regularly 141. 15 It s a SMOP 143,15 1 The Problem 143,15 2 Planning Game 144.
15 3 Dividing the Story into Tasks 145,15 4 Coding Style 146. 15 5 Simple Design 146,15 6 Imperative versus Declarative 147. 15 7 Pair Programming 149,15 8 Test First By Intention 149. 15 9 Statelessness 150,15 10XML Parser 151,15 11First SMOP 152. 15 12First Interpreter 153,15 13Functional Programming 154.
15 14Outside In 155,15 15May I Please 155,15 16Second Task 156. 15 17Unit Test Maintenance 157,15 18Second SMOP 158. 15 19Second SMOP Interpreter 159,15 20Spike Solutions 160. 15 21Third Task 160,15 22Third SMOP 162,15 23Third SMOP Interpreter 162. 15 24The Metaphor 164,15 25Fourth Task 164,15 26Fourth SMOP 166.
15 27Fourth SMOP Interpreter 167,15 28Object Oriented Programming 168. 15 29Success 169,15 30Virtual Pair Programming 169. c 2004 Robert Nagler vii,nagler extremeperl org,15 31Open Source Development with XP 170. 15 32Deviance Testing 171,15 33Final Implementation 172. 15 34Separate Concerns 177,15 35 Travel Light 178,c 2004 Robert Nagler viii.
nagler extremeperl org,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 communi. cate 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 To. gether 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,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 use. case 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. 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. c 2004 Robert Nagler x,nagler extremeperl org, do XP Fortunately Perl is fun and easy to code XP adds a modicum of. discipline to Perl coding practices that enables you to code faster and better. XP is reflective The code gets better because you refactor it frequently. This means you get to fix the bad code in the project that usually everybody. is afraid to touch With XP you might not be so afraid You and your pair. programming partner have lots of tests to ensure you don t break anything. while refactoring, The goal of refactoring is to represent concepts once and only once Perl. lets us do this more easily than other languages Extreme Perl code can. be quite compact without obfuscation rather the opposite The code often. evolves into what I call a subject matter oriented program SMOP. Subject matter oriented programming distills the essence of the prob. lem into a little language The SMOPs in this book are plain old Perl. There s no need to invent new syntax Sometimes you may need to think. differently to understand a SMOP unless you already are familiar with. declarative programming which is quite different than traditional imper. ative programming what most programmers learn in school. You need to know Perl fairly well to read many of the examples I. explain the examples without going into much detail about the Perl syntax. and semantics You may need to keep your favorite Perl reference book. within reach for example to undertand how map works. One last thing the some of test examples use the bivio OLTP Platform. bOP an open source application framework developed by my company. http www bivio biz If you write a lot of tests you need tools to help you. write them quickly and clearly bOP employs SMOP to simplify unit and. acceptance tests I m not trying to sell bOP to you it s free anyway but to. demonstrate SMOP in testing This book explains just enough of bOP to. read the examples,How to Read This Book, This book explains Extreme Perl to both programmers and business people.
I also attempt to convey the Extreme Perl experience through examples and. personal anecdotes The book covers Extreme Programming XP in detail. so no prior experience is necessary, The first part of this book is about the non programming aspects of Ex. treme Perl the why The Problem the what Extreme Programming and. Perl and the how Release Planning Iteration Planning Acceptance Test. ing Tracking and Pair Programming There is some code in Acceptance. c 2004 Robert Nagler xi,nagler extremeperl org, Testing but everybody should be able to read it The last chapter It s. a SMOP is an end to end Extreme Perl example that combines XP Perl. and SMOP Non programmers may want to scan this chapter and read the. conclusions at the end, The second part of this book contains numerous programming examples. from the real world The following chapters show you what it is like to. do Extreme Perl Coding Style Logistics Test Driven Design Continuous. Design Unit Testing Refactoring and It s a SMOP, If you are a top down thinker I recommend you read this book front to. back Bottom up thinkers may want to start at the last chapter and work. As noted in the previous section the Perl code in this book is advanced. The programming examples are not complex that is they are short and. contain only a few concepts However the code may appear complicated to. some programmers If you are familiar with functional programming and. object oriented Perl the examples should be clear If not you may want. to peek at the last chapter which describes functional programming The. references throughout the book may be helpful too The object oriented. aspects are not all that important so you should be able to understand the. examples without object oriented experience, Typographical notes I note acronyms that are used in the XP and Perl.
communities throughout this book but I use their expansions so you don t. have to memorize them,Acknowledgments, This book was a collaborative project Many people contribu. Perl is a dynamic programming language that lets an XP team embrace the inevitable change caused by e ective communication Perl is the xer and doer of the pair and XP is the organizer and facilitator To gether they help you build robust software applications e ciently Like any good marriage the partners of Extreme Perl support each other For example XP asks business people to write

Related Books