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.

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

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?

20. Legacy/Scary Code Dilemma

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

35. “Working with care”

37. Cover and Modify

40. Preserving existing behavior is one of the
largest challenges in software development.

41. Characterization Tests

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

55. Inject your dependency

57. “Slice” Show & Tell

58. https://twitter.com/kentbeck/status/250733358307500032?lang=en

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