Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Taming scary production code that nobody wants to touch

290 views

Published on

Most dev teams “own” some code that they don’t really want to work with. However it got there, the code is scary but pretty stable and requires updates. Perhaps your team draws straws to each time to figure out who is going to have to put on the metaphorical hazmat suit and deal with the problem. Or worse yet, your team relies on one developer to always do it and he or she is getting burned out and could leave at any minute.

Mike will share some techniques that will help you modify the code with confidence using a few core refactorings and characterization test.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Taming scary production code that nobody wants to touch

  1. 1. Taming scary production code that nobody wants to touch Mike Clement Founding Software Craftsman at Greater Sum mike@softwareontheside.com http://blog.softwareontheside.com http://www.greatersum.com
  2. 2. Modernizing Legacy Code Mike Clement Founding Software Craftsman at Greater Sum mike@softwareontheside.com http://blog.softwareontheside.com http://www.greatersum.com
  3. 3. What is Legacy Code?
  4. 4. Legacy code is code that we’ve gotten from someone else.
  5. 5. Legacy code is code that we’ve gotten from past-self.
  6. 6. A slang term for difficult-to-change code that we don’t understand.
  7. 7. Legacy code is simply code without tests.
  8. 8. Code without tests is bad code.
  9. 9. Code without tests is bad code?
  10. 10. Code without tests is scary code.
  11. 11. Legacy code (code without tests) is scary production code that nobody wants to touch.
  12. 12. Photo by Yung Chang on Unsplash
  13. 13. Risk
  14. 14. Photo by Leio McLaren on Unsplash
  15. 15. To mitigate risk, we have to ask three questions: 1. What changes do we have to make? 2. How will we know that we’ve done them correctly? 3. How will we know that we haven’t broken anything?
  16. 16. How much change can you afford if changes are risky?
  17. 17. Is it more important for the software system to work OR is it more important for the software system to be easy to change?
  18. 18. “If you give me a program that does not work but is easy to change, then I can make it work, and keep it working as requirements change. Therefore the program will remain continually useful.” Robert C. Martin
  19. 19. How do we keep software soft?
  20. 20. Legacy/Scary Code Dilemma
  21. 21. When we change code, we should have tests in place.
  22. 22. To put tests in place, we often have to change code.
  23. 23. Legacy Code Dilemma When we change code, we should have tests in place. To put tests in place, we often have to change code.
  24. 24. Low Risk Changes via Core Refactorings
  25. 25. re·fac·tor·ing (noun): a change made to the internal structure of software… without changing its observable behavior. https://martinfowler.com/bliki/DefinitionOfRefactoring.html
  26. 26. Core Refactorings as CRUD • Create: Introduce/Extract: • Local Variable • Method • Parameter • Field • Read: (performed by the human; no refactoring needed) • Update: Rename • Delete: Inline: • Local Variable • Method • Parameter • Field http://arlobelshee.com/the-core-6-refactorings/
  27. 27. Core Refactorings Demo Rental Store Code
  28. 28. To mitigate risk, we have to ask three questions: 1. What changes do we have to make? 2. How will we know that we’ve done them correctly? 3. How will we know that we haven’t broken anything?
  29. 29. Use your tools!
  30. 30. Preserving existing behavior is one of the largest challenges in software development.
  31. 31. Photo by Ben Koorengevel on Unsplash
  32. 32. Edit and Pray
  33. 33. Photo by Ian Espinosa on Unsplash
  34. 34. “Working with care”
  35. 35. Cover and Modify
  36. 36. Preserving existing behavior is one of the largest challenges in software development.
  37. 37. Characterization Tests
  38. 38. char·ac·ter·i·za·tion (noun) a description of the distinctive nature or features of something.
  39. 39. Characterization tests a means to protect existing behavior of legacy code against unintended changes
  40. 40. Characterization tests a means to describe (characterize) the actual behavior of an existing piece of software
  41. 41. Photo by Ksenia Makagonova on Unsplash
  42. 42. Do not check for “correctness” Check for existing behavior
  43. 43. Don’t have to understand
  44. 44. ApprovalTests Show & Tell An open source assertion/verification library to aid unit testing
  45. 45. Seams
  46. 46. A seam is a place where you can alter behavior in your program without editing in that place.
  47. 47. Method boundary
  48. 48. “Peel” Demo
  49. 49. Inject your dependency
  50. 50. “Slice” Show & Tell
  51. 51. https://twitter.com/kentbeck/status/250733358307500032?lang=en
  52. 52. Resources • Working Effectively with Legacy Code by Michael Feathers • Clean Architecture by Robert C. Martin • Peel & Slice videos by Llewellyn Falco • 6 Core Refactorings by Arlo Belshee
  53. 53. Mike Clement • @mdclement • mike@softwareontheside.com • http://blog.softwareontheside.com • https://github.com/mdclement • Greater Sum • @thegreatersum • http://www.greatersum.com • Software Craftsmanship Atlanta • Find us on meetup.com • Limited WIP Society Atlanta • Find us on meetup.com

×