Taming scary production code that nobody wants to touch
Download as PPTX, PDF•1 like•936 views
This document discusses strategies for working with legacy code that lacks tests, which is considered risky to change. It recommends using core refactorings to safely introduce tests and characterization tests to describe and protect existing behavior without changing it. Peeling away dependencies and slicing code into testable units also helps reduce risk when modifying untested code. The goal is to make legacy code less scary and easier to change over time by adding tests and refactoring carefully.
Taming scary production code that nobody wants to touch
- 1. Taming scary production code that nobody wants to touch Mike Clement Founding Software Craftsman at Greater Sum [email protected] http://blog.softwareontheside.com http://www.greatersum.com
- 2. Modernizing Legacy Code Mike Clement Founding Software Craftsman at Greater Sum [email protected] http://blog.softwareontheside.com http://www.greatersum.com
- 3. What is Legacy Code?
- 4. Legacy code is code that we’ve gotten from someone else.
- 5. Legacy code is code that we’ve gotten from past-self.
- 6. A slang term for difficult-to-change code that we don’t understand.
- 7. Legacy code is simply code without tests.
- 8. Code without tests is bad code.
- 9. Code without tests is bad code?
- 10. Code without tests is scary code.
- 11. Legacy code (code without tests) is scary production code that nobody wants to touch.
- 12. Photo by Yung Chang on Unsplash
- 13. Risk
- 14. Photo by Leio McLaren on Unsplash
- 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. How much change can you afford if changes are risky?
- 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. “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. How do we keep software soft?
- 21. When we change code, we should have tests in place.
- 22. To put tests in place, we often have to change code.
- 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. Low Risk Changes via Core Refactorings
- 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. 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. Core Refactorings Demo Rental Store Code
- 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. Use your tools!
- 30. Preserving existing behavior is one of the largest challenges in software development.
- 31. Photo by Ben Koorengevel on Unsplash
- 33. Edit and Pray
- 34. Photo by Ian Espinosa on Unsplash
- 37. Cover and Modify
- 40. Preserving existing behavior is one of the largest challenges in software development.
- 42. char·ac·ter·i·za·tion (noun) a description of the distinctive nature or features of something.
- 43. Characterization tests a means to protect existing behavior of legacy code against unintended changes
- 44. Characterization tests a means to describe (characterize) the actual behavior of an existing piece of software
- 46. Photo by Ksenia Makagonova on Unsplash
- 47. Do not check for “correctness” Check for existing behavior
- 48. Don’t have to understand
- 49. ApprovalTests Show & Tell An open source assertion/verification library to aid unit testing
- 50. Seams
- 51. A seam is a place where you can alter behavior in your program without editing in that place.
- 52. Method boundary
- 54. “Peel” Demo
- 57. “Slice” Show & Tell
- 59. 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
- 60. Mike Clement • @mdclement • [email protected] • 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
Editor's Notes
- #22: The Legacy Code Dilemma
- #23: The Legacy Code Dilemma
- #34: then you poke around further to make sure that you didn’t break anything. The poking around is essential. When you make your changes, you are hoping and praying that you’ll get them right, and you take extra time when you are done to make sure that you did.
- #46: When we have tests that detect change, it is like having a vise around our code.
- #54: Peel off the dependency
- #59: for each desired change, make the change easy (warming: this may be hard), then make the easy change Kent Beck