Mud Tires: Getting Traction in Legacy Code

  • 1,453 views
Uploaded on

In this talk from the Tampa IASA User Group, Cory Foy gives Tools, Strategies and Approaches for dealing with Legacy Code.

In this talk from the Tampa IASA User Group, Cory Foy gives Tools, Strategies and Approaches for dealing with Legacy Code.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,453
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
21
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • \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

Transcript

  • 1. MUD TIRES: GETTINGTRACTION 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
  • 2. http://www.flickr.com/photos/countylemonade/5417832718
  • 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
  • 9. http://www.flickr.com/photos/futureshape/2614476028
  • 10. Preparing to AddBehavior
  • 11. Adding BehaviorPreparing to AddBehavior
  • 12. Adding BehaviorPreparing Removing to Add DuplicationBehavior
  • 13. Cleaning Technical Debt Adding BehaviorPreparing Removing to Add DuplicationBehavior
  • 14. Cleaning Technical Debt Adding BehaviorPreparing Removing to Add DuplicationBehavior
  • 15. Cleaning Technical Debt Adding Behavior Preparing Removing to Add Duplication Behavior r e f ac t o r i ngP
  • 16. Cleaning Technical Debt Adding Behavior Preparing Removing to Add Duplication Behavior o r i ng Re f ac tPre f ac t o r i ng
  • 17. 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 tPre f ac t o r i ng
  • 18. 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 tPre f ac t o r i ng
  • 19. http://www.flickr.com/photos/marcwathieu/4074508950
  • 20. Tools Strategies Approaches http://www.flickr.com/photos/marcwathieu/4074508950
  • 21. http://www.flickr.com/photos/pitel/1406292257
  • 22. http://www.flickr.com/photos/pitel/1406292257
  • 23. http://www.flickr.com/photos/pitel/1406292257
  • 24. http://www.flickr.com/photos/pitel/1406292257
  • 25. http://www.flickr.com/photos/pitel/1406292257
  • 26. http://www.flickr.com/photos/pitel/1406292257
  • 27. http://www.flickr.com/photos/pitel/1406292257
  • 28. http://www.flickr.com/photos/pitel/1406292257
  • 29. ra te g ie sSt Naked CRC Acceptance Test-Driven Development Test-Driven Development Refactoring Tell the Story Pair ProgrammingSensing Variables Characterization Tests
  • 30. ra te g ie sSt Naked CRC Acceptance Test-Driven Development Test-Driven Development Refactoring Tell the Story Pair ProgrammingSensing Variables Characterization Tests
  • 31. ra te g ie sSt Making Changes Acceptance Test-Driven Development Test-Driven Development Refactoring Gaining Understanding Tell the StoryIncreasing Confidence Naked CRCPair ProgrammingCharacterization TestsSensing Variables
  • 32. Tell the Story Naked CRChttp://www.flickr.com/photos/ransomtech/5811447011
  • 33. Tell the Story
  • 34. Naked CRC
  • 35. Increasing Confidence Sensing VariablesCharacterization Tests Pair Programming http://www.flickr.com/photos/west_point/5863829218
  • 36. Sensing Variableshttp://www.artima.com/weblogs/viewpost.jsp?thread=170799
  • 37. Sensing Variableshttp://www.artima.com/weblogs/viewpost.jsp?thread=170799
  • 38. Sensing Variableshttp://www.artima.com/weblogs/viewpost.jsp?thread=170799
  • 39. Characterization Testshttp://www.artima.com/weblogs/viewpost.jsp?thread=170799
  • 40. Characterization Testshttp://www.artima.com/weblogs/viewpost.jsp?thread=170799
  • 41. Characterization Testshttp://www.artima.com/weblogs/viewpost.jsp?thread=170799
  • 42. You need to ATDD TDD Refactoring Changhttp://www.flickr.com/photos/slavin_fpo/3728404776
  • 43. 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 tPre f ac t o r i ng
  • 44. 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 tPre f ac t o r i ng
  • 45. 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 tPre f ac t o r i ng
  • 46. 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 tPre f ac t o r i ng
  • 47. 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
  • 48. 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
  • 49. 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
  • 50. http://www.fitnesse.org
  • 51. http://www.fitnesse.org
  • 52. http://www.fitnesse.org
  • 53. http://www.fitnesse.org
  • 54. A test is not a unit test if:- It talks to the database- It communicates across the network- It touches the file system- It cant run at the same time as any of your otherunit tests- You have to do special things to your environment(such as editing config files) to run it.
  • 55. http://vinkamat.com/2011/tdd-unit-testing-and-benefits/
  • 56. Redhttp://vinkamat.com/2011/tdd-unit-testing-and-benefits/
  • 57. RedGreenhttp://vinkamat.com/2011/tdd-unit-testing-and-benefits/
  • 58. RedGreenRefactorhttp://vinkamat.com/2011/tdd-unit-testing-and-benefits/
  • 59. (Refactoring is a) disciplined technique forrestructuring an existing body of code, alteringits internal structure without changing itsexternal behavior
  • 60. Feather’s Approach ATDD Approach Edit and Pray http://www.flickr.com/photos/phluke/62175794
  • 61. Feather’s Approach
  • 62. Feather’s ApproachIdentifyChange Points
  • 63. Feather’s ApproachIdentifyChange PointsFind Test Points
  • 64. Feather’s ApproachIdentifyChange PointsFind Test Points Break Dependencie s
  • 65. Feather’s ApproachIdentifyChange Write Points TestsFind Test Points Break Dependencie s
  • 66. Feather’s ApproachIdentifyChange Write Points TestsFind Test Points Make Changes Break Dependencie s
  • 67. Feather’s ApproachIdentifyChange Write Points TestsFind Test Points Make Changes Break Dependencie Refactor s
  • 68. ATDD Approach
  • 69. Write ATDD ApproachAcceptance Tests
  • 70. Write ATDD ApproachAcceptance Tests Write Characterization Tests
  • 71. Write ATDD ApproachAcceptance Tests Write Characterization Tests Implement Behavior
  • 72. Write ATDD ApproachAcceptance Tests Write Characterization Tests Implement Behavior Get All Tests to Pass
  • 73. Write ATDD ApproachAcceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
  • 74. Write ATDD ApproachAcceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
  • 75. Write ATDD ApproachAcceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
  • 76. Write ATDD ApproachAcceptance Tests Write Characterization Tests Celebrate! Implement Behavior Get All Tests to Pass
  • 77. e fe re n ce sRCory Foyfoyc@coryfoy.com@cory_foycory.foy@netobjectives.com http://www.flickr.com/photos/or4n6e/4827075541