Mud Tires: Getting Traction in Legacy Code
•Transferir como KEY, PDF•
2 gostaram•1,416 visualizações
In this talk from the Tampa IASA User Group, Cory Foy gives Tools, Strategies and Approaches for dealing with Legacy Code.
Recomendados
Mais conteúdo relacionado
Semelhante a Mud Tires: Getting Traction in Legacy Code
Semelhante a Mud Tires: Getting Traction in Legacy Code (20)
Mais de Cory Foy
Mais de Cory Foy (20)
Último
Último (20)
Mud Tires: Getting Traction in Legacy Code
- 1. MUD TIRES: GETTING TRACTION IN LEGACY CODE o r y_ f oy Cory Foy @ c i ve s .c om Senior Consultant e tob je c t Net Objectives y.f o y@n f oy .c om cor lo g. cor y ht p:/ b t / http://www.flickr.com/photos/or4n6e/4827075541
- 3. WHAT IS LEGACY CODE?
- 4. WHAT IS LEGACY CODE? • Code we’ve gotten from somewhere else
- 5. WHAT IS LEGACY CODE? • Code we’ve gotten from somewhere else • Code we have to change, but don’t understand
- 6. WHAT IS LEGACY CODE? • Code we’ve gotten from somewhere else • Code we have to change, but don’t understand • Demoralizing Code (Big Ball of Mud)
- 7. WHAT IS LEGACY CODE? • Code we’ve gotten from somewhere else • Code we have to change, but don’t understand • Demoralizing Code (Big Ball of Mud) • Code without automated unit tests
- 8. WHAT IS LEGACY CODE? • Code we’ve gotten from somewhere else • Code we have to change, but don’t understand • Demoralizing Code (Big Ball of Mud) • Code without automated unit tests • Any code older than about 2 hours
- 12. Adding Behavior Preparing to Add Behavior
- 13. Adding Behavior Preparing Removing to Add Duplication Behavior
- 14. Cleaning Technical Debt Adding Behavior Preparing Removing to Add Duplication Behavior
- 15. Cleaning Technical Debt Adding Behavior Preparing Removing to Add Duplication Behavior
- 16. Cleaning Technical Debt Adding Behavior Preparing Removing to Add Duplication Behavior r e f ac t o r i ng P
- 17. Cleaning Technical Debt Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac t Pre f ac t o r i ng
- 18. R e mo d e li ng Cleaning Technical Debt Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac t Pre f ac t o r i ng
- 19. R e mo d e li ng Cleaning Technical Debt Coding Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac t Pre f ac t o r i ng
- 22. Tools Strategies Approaches http://www.flickr.com/photos/marcwathieu/4074508950
- 40. ra te g ie s St Naked CRC Acceptance Test-Driven Development Test-Driven Development Refactoring Tell the Story Pair Programming Sensing Variables Characterization Tests
- 41. ra te g ie s St Naked CRC Acceptance Test-Driven Development Test-Driven Development Refactoring Tell the Story Pair Programming Sensing Variables Characterization Tests
- 42. ra te g ie s St Making Changes Acceptance Test-Driven Development Test-Driven Development Refactoring Gaining Understanding Tell the Story Increasing Confidence Naked CRC Pair Programming Characterization Tests Sensing Variables
- 43. Tell the Story Naked CRC http://www.flickr.com/photos/ransomtech/5811447011
- 44. Tell the Story
- 45. Naked CRC
- 46. Increasing Confidence Sensing Variables Characterization Tests Pair Programming http://www.flickr.com/photos/west_point/5863829218
- 57. You need to ATDD TDD Refactoring Chang http://www.flickr.com/photos/slavin_fpo/3728404776
- 58. R e mo d e li ng Cleaning Technical Debt Coding Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac t Pre f ac t o r i ng
- 59. R e mo d e li ng Cleaning ATDD Technical Debt Coding Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac t Pre f ac t o r i ng
- 60. R e mo d e li ng Cleaning ATDD Technical TDD Debt Coding Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac t Pre f ac t o r i ng
- 61. R e mo d e li ng Cleaning ATDD Technical TDD Debt Refactoring Coding Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac t Pre f ac t o r i ng
- 62. Example: Acceptance TDD Basic Employee Compensation Each week, hourly employees are paid • A standard wage per hour for the first 40 hours worked • 1.5 times their wage for each hour after the first 40 hours • 2 times their wage for each hour worked on Sundays and holidays
- 63. Example: Acceptance TDD Basic Employee Compensation Each week, hourly employees are paid • A standard wage per hour for the first 40 hours worked • 1.5 times their wage for each hour after the first 40 hours • 2 times their wage for each hour worked on Sundays and holidays Payroll.Fixtures.WeeklyCompensation Standard Hol/Sun Wage Pay() Hours Hours 40 0 20 45 0 20 48 8 20
- 64. Example: Acceptance TDD Basic Employee Compensation Each week, hourly employees are paid • A standard wage per hour for the first 40 hours worked • 1.5 times their wage for each hour after the first 40 hours • 2 times their wage for each hour worked on Sundays and holidays Payroll.Fixtures.WeeklyCompensation Standard Hol/Sun Wage Pay() Hours Hours 40 0 20 $800 45 0 20 $950 48 8 20 $1520
- 69. A test is not a unit test if: - It talks to the database - It communicates across the network - It touches the file system - It can't run at the same time as any of your other unit tests - You have to do special things to your environment (such as editing config files) to run it.
- 82. (Refactoring is a) disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior
- 88. Feather’s Approach ATDD Approach Edit and Pray http://www.flickr.com/photos/phluke/62175794
- 91. Feather’s Approach Identify Change Points Find Test Points
- 92. Feather’s Approach Identify Change Points Find Test Points Break Dependencie s
- 93. Feather’s Approach Identify Change Write Points Tests Find Test Points Break Dependencie s
- 94. Feather’s Approach Identify Change Write Points Tests Find Test Points Make Changes Break Dependencie s
- 95. Feather’s Approach Identify Change Write Points Tests Find Test Points Make Changes Break Dependencie Refactor s
- 96. ATDD Approach
- 97. Write ATDD Approach Acceptance Tests
- 98. Write ATDD Approach Acceptance Tests Write Characterization Tests
- 99. Write ATDD Approach Acceptance Tests Write Characterization Tests Implement Behavior
- 100. Write ATDD Approach Acceptance Tests Write Characterization Tests Implement Behavior Get All Tests to Pass
- 101. Write ATDD Approach Acceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
- 102. Write ATDD Approach Acceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
- 103. Write ATDD Approach Acceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
- 104. Write ATDD Approach Acceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
- 106. e fe re n ce s R Cory Foy foyc@coryfoy.com @cory_foy cory.foy@netobjectives.com http://www.flickr.com/photos/or4n6e/4827075541
Notas do Editor
- \n
- What is legacy code? (Get answers from audience)\n
- But the key attribute between all of these is that we have to...\n
- But the key attribute between all of these is that we have to...\n
- But the key attribute between all of these is that we have to...\n
- But the key attribute between all of these is that we have to...\n
- But the key attribute between all of these is that we have to...\n
- Have to preserve behavior. If we aren’t preserving behavior, we are just rewriting, and can follow the rules of writing new, clean code. Or we can just delete it (negative KLOC metrics, anyone?). But eventually we have to do something with it\n
- The four main things are these. Event driven (making a change because of new behavior) vs investment driven (cleaning tech debt)\n
- The four main things are these. Event driven (making a change because of new behavior) vs investment driven (cleaning tech debt)\n
- The four main things are these. Event driven (making a change because of new behavior) vs investment driven (cleaning tech debt)\n
- The four main things are these. Event driven (making a change because of new behavior) vs investment driven (cleaning tech debt)\n
- The four main things are these. Event driven (making a change because of new behavior) vs investment driven (cleaning tech debt)\n
- The four main things are these. Event driven (making a change because of new behavior) vs investment driven (cleaning tech debt)\n
- We can label them like this. Refactoring has gotten a bad name - if we are making big changes, we are remodeling, not refactoring. No matter which thing we are choosing, we have to follow the guiding principle of legacy code\n
- We can label them like this. Refactoring has gotten a bad name - if we are making big changes, we are remodeling, not refactoring. No matter which thing we are choosing, we have to follow the guiding principle of legacy code\n
- We can label them like this. Refactoring has gotten a bad name - if we are making big changes, we are remodeling, not refactoring. No matter which thing we are choosing, we have to follow the guiding principle of legacy code\n
- We can label them like this. Refactoring has gotten a bad name - if we are making big changes, we are remodeling, not refactoring. No matter which thing we are choosing, we have to follow the guiding principle of legacy code\n
- Which is to keep the system running at all times. To do this, we have to treat everything as a series of small changes, or refactorings, to get us to where we want to go\n
- To do *that* we need three things.\n
- To do *that* we need three things.\n
- To do *that* we need three things.\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper, Cucumber, FitNesse, TeamCity, NUnit/JUnit/PHPUnit. Demo the tools\n
- Resharper. The heavyweight of refactoring tools for .NET. \n
- Resharper. The heavyweight of refactoring tools for .NET. \n
- Resharper. The heavyweight of refactoring tools for .NET. \n
- TeamCity - for Continuously insuring the code is buildable\n
- NUnit and unit testing tools for writing automated unit tests (and TD.NET for running in VS)\n
- Cucumber for communicating with the non-technical members\n
- FitNesse is another way of communicating with non-technical users. Tools are great, but not by themselves. You need strategies for using them.\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- There are lots and lots of strategies available\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- But we can categorize them into three broad areas - Gaining Understanding, Increasing Confidence and Making Changes\n
- Gaining Understanding. Tell the Story, Naked CRC. Let’s apply these to two pieces of legacy code.\n
- Tell a story (or pick an example from the audience)\n
- Naked CRC. Class Responsibility Collaboration (CRC) cards are a brainstorming tool used in the design of object-oriented software. They were proposed by Ward Cunningham and Kent Beck. [1] They are typically used when first determining which classes are needed and how they will interact.\nCRC cards are usually created from index cards on which are written:\nThe class name\nIts Super and Sub classes (if applicable)\nThe responsibilities of the class.\nThe names of other classes with which the class will collaborate to fulfill its responsibilities.\nAuthor\n Next is Increasing Confidence in making changes\n
- Characterization Tests, Sensing Variables, Pair Programming\n
- Sensing Variables and Characterization Tests (see the link at the bottom of the slide for more info)\n
- Sensing Variables and Characterization Tests (see the link at the bottom of the slide for more info)\n
- Note we could use a debugger, but this lets us come at it from different angles. We also won’t leave the variable in there long term - extract out the method, then test using that\n
- Note we could use a debugger, but this lets us come at it from different angles. We also won’t leave the variable in there long term - extract out the method, then test using that\n
- Pair Programming - Ping Pong Programming\n
- Old Pair Programming Setup\n
- Old Pair Programming Setup\n
- Next is making changes to the code base\n
- ATDD, TDD, Refactoring\n
- ATDD helps us prep and add behavior. TDD helps us Add behavior and prep to remove duplication. Refactoring helps us remove duplication\n
- ATDD helps us prep and add behavior. TDD helps us Add behavior and prep to remove duplication. Refactoring helps us remove duplication\n
- ATDD helps us prep and add behavior. TDD helps us Add behavior and prep to remove duplication. Refactoring helps us remove duplication\n
- ATDD helps us prep and add behavior. TDD helps us Add behavior and prep to remove duplication. Refactoring helps us remove duplication\n
- ATDD helps us prep and add behavior. TDD helps us Add behavior and prep to remove duplication. Refactoring helps us remove duplication\n
- ATDD helps us prep and add behavior. TDD helps us Add behavior and prep to remove duplication. Refactoring helps us remove duplication\n
- \n
- \n
- $800 for the first line is clear.\n$950 may not be clear, but it is 40 @ $20/hr + 5 @ $30/hr\nThe $1520 may not be clear. I could think: 40 @ $20/hr + 8 @ $30/hr + 8 * $40 = $1360. But that is wrong.\nThe 8 Holiday Hours get paid time and a half of double time. So it should be:\n 40 @ $20/hr + 8 @ $30/hr + 8 * $60 = $1520\n
- Write the Wiki Syntax\n
- Write some code to make it fail\n
- Write the code to make it pass\n
- Can be more natural language-ish\n
- To talk about TDD, we need to first talk about unit tests. This is Michael Feather’s definition.\n
- TDD\n
- TDD\n
- TDD\n
- TDD\n
- TDD\n
- TDD\n
- TDD example with Ruby and RSpec\n
- TDD example with Ruby and RSpec\n
- TDD example with Ruby and RSpec\n
- TDD example with Ruby and RSpec\n
- Martin Fowler’s definition of refactoring\n
- Refactorings available in Resharper, with common ones circled\n
- Refactorings available in Resharper, with common ones circled\n
- Refactorings available in Resharper, with common ones circled\n
- Refactorings available in Resharper, with common ones circled\n
- Approaches - Feather’s Change Approach, ATDD Approach, Edit and Pray\n
- Feather’s Change Approach: Identify Change Points, Find Test Points, Break Dependencies, Write Tests, Make Changes and Refactor\n
- Feather’s Change Approach: Identify Change Points, Find Test Points, Break Dependencies, Write Tests, Make Changes and Refactor\n
- Feather’s Change Approach: Identify Change Points, Find Test Points, Break Dependencies, Write Tests, Make Changes and Refactor\n
- Feather’s Change Approach: Identify Change Points, Find Test Points, Break Dependencies, Write Tests, Make Changes and Refactor\n
- Feather’s Change Approach: Identify Change Points, Find Test Points, Break Dependencies, Write Tests, Make Changes and Refactor\n
- Feather’s Change Approach: Identify Change Points, Find Test Points, Break Dependencies, Write Tests, Make Changes and Refactor\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- ATDD Approach - Write Tests for the behavior you want. Write tests to characterize the current behavior. Use TDD to implement the new behavior until your acceptance tests pass.\n
- Edit and Pray\n
- \n