sitBRU - The Hitchhikers Guide to the Legacy
- 1. The Hitchhikers Guide to the Legacy sitBRU | 18 May 2019 | Laurens van Rijn SAP Inside Track presentation
- 2. Agenda Today’s topics ―What is Legacy Code? ―Is Legacy Code bad? ―Is Legacy Code good? ―The way forward ―Working with Legacy Code ―Want to know more? ―Q&A HHGtt Legacy
- 3. … in large friendly letters on its cover. HHGtt Legacy
- 4. What is Legacy Code? (1/2) Some definitions… ―“Code where you can see the different programming styles of all the developers who ever worked on it” – Ginny Hendry ―“Code that we don't like any more for whatever reason (typically because it's not cool or fashionable but it works” – Dan Dyer ―“The code base or platform on which it is built is so old that getting qualified or experienced developers for the system is both hard and expensive” – Anonymous ―“ABAP code, riddled with deprecated statements (OCCURS etc.), usually written under considerable time pressure and badly documented by developers who have since left the company and who laugh at you upon learning you’re supporting their code when meeting them at events” – Me ―“Simply code without tests” – Michael Feathers HHGtt Legacy
- 5. What is Legacy Code? (2/2) Our working definition “Code without tests is a bad code. It doesn’t matter how well written it is; how well structured it is; how well encapsulated it is. Without tests there is no way to tell if our code is getting better or worse.” – Michael Feathers Please note: Your Legacy Code is not the same as your Code Legacy. The latter partly determines your standing in the company as well as the likelihood you’ll be invited back for another assignment. HHGtt Legacy
- 6. Is Legacy Code bad? (Spoiler alert) Of course it’s not… Legacy Code… ―Supports the company’s business processes ―Brings in revenue ―Provides learning moments and challenging puzzles HHGtt Legacy
- 7. Is Legacy Code good? (Spoiler alert) Of course it’s not… Legacy Code is… ―Complicated ―Likely to fall apart when touched ―Time consuming ―Bad for morale The business may become hesitant to change due to the risks and costs of changing legacy code. HHGtt Legacy
- 8. Legacy (Code) is everywhere… HHGtt Legacy
- 9. The way forward (1/2) Why should we want to get a grip on Legacy Code? ―Improved efficiency ―Reduced development costs ―Improved product quality ―Lower learning curve Thereby allowing the business the freedom to change as needed and be supported by their software systems. HHGtt Legacy
- 10. The way forward (2/2) How can we achieve this? ―Edit & Pray vs Cover & Modify ―Test Driven Development The Legacy Code Dilemma: when we change code, we want to have tests in place. To put tests in place, we need to change code. So, we… ―Identify change points ―Find test points ―Break dependencies ―Write tests ―Make changes and refactor HHGtt Legacy
- 11. Working with Legacy Code (1/5) Identify change points ―I don’t understand the code well enough to change it 1. Sketching 2. Listing mark-up 3. Scratch refactoring 4. Delete unused code ―My application has no structure 1. Telling the story 2. Naked CRC HHGtt Legacy
- 12. Working with Legacy Code (2/5) Find test points ―I need to make a change, what methods should I test? 1. Effect analysis → Effect sketch 2. Where are values changed, stored and who is using them? ―I need to make many changes in one area, do I have to break dependencies for all the classes involved? 1. (High level) interception points 2. Pinch points HHGtt Legacy
- 13. Working with Legacy Code (3/5) Break dependencies ―How do I know I’m not breaking anything? 1. Hyperaware & single goal editing 2. Preserve signatures 3. Lean on the compiler 4. Pair programming ―I need to change a monster method and I can’t write tests for it 1. A plethora of monsters (bulleted, snarled, and mixed) 2. Refactoring: automated or manual HHGtt Legacy
- 14. Working with Legacy Code (4/5) Write tests ―I need to make a change but I don’t know what tests to write 1. Use characterization tests (from failure to good result) 2. What if you encounter bugs? ―My test code is in the way 1. Naming conventions (FAKE… / …TEST / TESTING… / MOCK…) 2. Documentation HHGtt Legacy
- 15. Working with Legacy Code (5/5) Make changes and refactor ―I don’t have much time and I have to change it 1. Sprout 2. Wrap ―I’m changing the same code all over the place 1. Necessary to remove redundancy? 2. Extract the difference from similar methods and use a common method 3. Open / Closed principle HHGtt Legacy
- 16. Want to know more? The book (contains so much more, worth reading) ―https://www.goodreads.com/book/show/44919.Working_Effectively_with_Le gacy_Code Literature ―https://en.wikipedia.org/wiki/Legacy_code ―https://stackoverflow.com/questions/479596/what-makes-code-legacy ―https://en.wikipedia.org/wiki/Test-driven_development ―https://en.wikipedia.org/wiki/Technical_debt ―https://en.wikipedia.org/wiki/Towel_Day ―https://open.sap.com/courses/wtc1 HHGtt Legacy
- 17. Say hello to Q&A
- 18. Thank you Contact information Laurens van Rijn Sr. SAP Technology Consultant Experis Ciber Flight Forum 840 5657 DV Eindhoven [email protected] HHGtt Legacy
Editor's Notes
- #2: Legacy is everywhere, the hash tag is sitBRU but we’re gathered here today in Kontich…
- #4: This presentation is future proof and cloud ready. You can start using it today and it will continue to work…
- #5: 0 Question for the audience… 1 Legacy Code is un[clean code]... 1 “How your code will be viewed by the next generation of developers” – Ginny Hendry 1 “Rotten code” – Robert Martin 2 Difference between Legacy Code and your Code Legacy: your Code Legacy will influence the chance of being asked for other/repeat assignments…
- #11: Unit Testing (error localization, execution time and coverage)
- #13: For all methods you change. Is that enough? Low coupling, high cohesion. Find all object that can influence the objects you’re changing Global and static variables, super and subclasses. Interception Point: where you can detect the effects of a change. Pinch Point: where a test for a few methods can detect the changes in many methods.
- #14: Book dates from 2005, version management and new tools negate 2 and 3. Pretty Printer helps too. Code Inspector allows you to set limits on number of lines, reducing the likelihood of monster spawning. Extract what you know, gleaning dependencies (test what is critical), extract small pieces
- #15: 1) First create a failure. Based on the result of that failure you’ll now what is needed to make it pass. 2) Bugs are a byproduct; you’re documenting the behavior of the code for future use to avoid doing it again and again…
- #16: Add new code in a new method. +Code is separated. – Old code still not improved. Class combines multiple methods. + New code centralized. – Hierarchy muddled. New method calls the old method and does something before or after the call. Class wraps an entire class. Do this for completely unrelated behavior or to limit the wrapped class in functionality. Fighting redundancy… Not always relevant Refactoring: a change made to the internal structure of the code to make it easier to understand and cheaper to modify without changing its existing behavior… Open for extension, closed for modification.