Three Principles To Bring Your Legacy Code Into the Future

1. @Ro_Wei Roland Weisleder roland@rweisleder.de Three Principles To Bring Your Legacy Code Into the Future
2. About Me Independent Software Developer & Consultant Bringing Legacy Java Systems Into the Future Spring Boot Trainer @ workshops.de Lecturer @ HTW Berlin in/roland-weisleder @rweisleder @Ro_Wei roland@rweisleder.de
3. What is Legacy Code?* • Still in production use • Relies on outdated technologies • Has insufficient test coverage • Lacks adequate documentation • Expert knowledge unavailable *According to ChatGPT
4. Big Bang Rewrite? Too time-consuming
5. What to improve? What you work on anyway
6. Rewrite or Refactor? Rewrite only with test coverage
7. Old bugs need to be added to the rewritten system. Source: https://martinfowler.com/bliki/StranglerFigApplication.html
8. How to increase test coverage? Add tests for current behavior
9. How to understand the current behavior?
10. Where to start?
11. Source: https://www.commitstrip.com/en/2016/03/03/its-not-working/
12. Analyze Stack Trace or Thread Dump Source: https://www.jetbrains.com/help/idea/analyzing-external-stacktraces.html
13. Call Hierarchy
14. Source: https://twitter.com/codewisdom/status/1154436195126009858
15. Understand Code
16. Scratch Refactoring • Learn through refactoring • Make experiments • Revert everything
17. Source: https://www.morling.dev/blog/the-code-review-pyramid/
18. Document Code
19. Our code is self-documenting.
20. • What about the input format? • What about malformed input? • What about null? • What about thrown exceptions?
21. • What about the return value? * don’t use double for money…
22. Suddenly a wild Java update appears
23. Unit tests are our documentation.
24. Who has read the tests of their favorite language / framework / library to understand how to use it?
27. not only Don‘t Repeat Yourself but also Documentation Reflects Implementation
28. Source: https://twitter.com/sweblogtweets/status/1249698475249467393
29. Test Code
30. What should I test? The documented behavior.
31. Use Descriptive Test Names
32. Concise Implementation Keep relevant stuff together, hide irrelevant stuff
33. I want to test private methods Private methods are independent units in disguise. Extract, document and test.
34. I have to mock everything So the method does nothing useful? Keep it simple, delete the method.
35. The code contains hard-to-mock dependencies Current Time Database External Systems
36. Declare dependencies as parameters vs vs
37. Declare dependencies as parameters vs
38. Separate Domain and Infrastructure to simplify testing
39. Clean Architecture
40. Code Coverage • Find untested code • Find dead code
41. Still doing Scratch Refactoring? Revert everything, except the tests. Congratulations! Time for TDD.
42. Inverted TDD
43. Source: https://twitter.com/kentbeck/status/250733358307500032
44. Improve Code
45. Source: https://www.morling.dev/blog/the-code-review-pyramid/
46. Focus on clean APIs
47. Define Interfaces Input Process Output
48. Invalid objects …
49. … vs valid objects
50. What about null?
51. Primitive Obsession vs
52. Source: https://twitter.com/codewisdom/status/1154436195126009858
54. https://www.youtube.com/watch?v=OGZ1JkC-cQc
55. Key Takeaways Separate Domain and Infrastructure Documentation Reflects Implementation Input Process Output
56. Bringing Legacy Code Into the Future Slides: speakerdeck.com/rweisleder Gilded Rose Kata: github.com/emilybache/GildedRose-Refactoring-Kata Need help with your Legacy Code? Contact me! roland@rweisleder.de in/roland-weisleder @rweisleder @Ro_Wei