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.
AI Mastery 201: Elevating Your Workflow with Advanced LLM Techniques
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
mike@softwareontheside.com
http://blog.softwareontheside.com
http://www.greatersum.com
2. Modernizing Legacy Code
Mike Clement
Founding Software Craftsman at Greater Sum
mike@softwareontheside.com
http://blog.softwareontheside.com
http://www.greatersum.com
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?
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
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/
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?
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
• 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
Editor's Notes
The Legacy Code Dilemma
The Legacy Code Dilemma
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.
When we have tests that detect change, it is like having a vise around our code.
Peel off the dependency
for each desired change, make the change easy (warming: this may be hard), then make the easy change
Kent Beck