Approaching Legacy Systems

Sharing my experiences on How to take over legacy applications on MagmaTalks Open Session

Transcript

1. Empowering innovation through collaboration
2. APPROACHING LEGACY SYSTEMS Victor Velázquez Director of Engineering at MagmaLabs
3. AGENDA 1. Defini(on and mindset 2. Just look at the files 3. Become a Git historian 4. Look for documenta(on 5. Understand your boundaries 6. The daily boy scout 7. Don’t repeat yourself 8. Sta(c analysis tools 9. Understand your tests 10.Extract features 11.Adopt a few core ideas
4. Wikipedia definition In compu(ng, a legacy system is an old method, technology, computer system, or applica(on program, "of, rela(ng to, or being a previous or outdated computer system." OUen a pejora(ve term, referencing a system as "legacy" means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement. 1. DEFINITION AND MINDSET
5. Get ready for an archeology trip Start wri(ng down notes of everything you are learning It does not have to be a book, keywords may be enough Mind maps are great 1. DEFINITION AND MINDSET
6. 2. JUST LOOK AT THE FILES Use ls to look for clues on what the domain knowledge looks like:
7. 2. JUST LOOK AT THE FILES Use tree to look deeper:
8. 2. JUST LOOK AT THE FILES Use find, sort, sed, uniq, head to get the top counts per file type:
9. 3. BECOME A GIT HISTORIAN Use git-extras to get a summary of the project $ brew install git-extras $ git summary ➤ You can also go to github in case it is stored in github
10. 3. BECOME A GIT HISTORIAN Understand change on single objects with git log: 
 $ git log --patch --stat Gemfile
 

11. 3. BECOME A GIT HISTORIAN You can go fancy with git-history:
 
 Travel Machine (trhough Git History)
12. 4. LOOK FOR DOCUMENTATION As we look for documenta(on keep in mind: 1. Is there any documenta(on at all? 2. Is there good commentary on the code? 3. Does the names of things make sense? 4. Are the system use cases are documented? 5. Is there someone in the team that understand the system?
13. 4. LOOK FOR DOCUMENTATION Seems that we have a doc folder: The last document modified on 2016, so it's time to start your documentation.
14. 4. LOOK FOR DOCUMENTATION Poor README
15. 4. LOOK FOR DOCUMENTATION There are a lot of templates you can use (if you feels like)
16. 4. LOOK FOR DOCUMENTATION Here are a few things to keep in mind: Document everything you learn. Keep documenta(on close to the code, simple is becer. You must understand the design/architecture. Once you understand something refine it's documenta(on.
17. 5. UNDERSTAND YOUR BOUNDARIES One way to help you understand the architecture is to understand the boundaries. Let's start with your Gemfile:
18. 5. UNDERSTAND YOUR BOUNDARIES Remember your notes Draw how the boundaries look like You don't need to follow a specific methodology, just draw
19. 5. UNDERSTAND YOUR BOUNDARIES Try Rubrowser
20. 5. UNDERSTAND YOUR BOUNDARIES Try rails-erd
21. 6. THE DAILY BOY SCOUT From Uncle Bob: Always leave the campground cleaner than you found it. Excuses are many, get over them Now let's figure out where to start
22. 7. DON’T REPEAT YOURSELF Review your views (tons of duplicated code)
23. 8. STATIC ANALYSIS TOOLS Let's take a look to only a few of its tools: churn reek code_metrics rubocop unused
24. 8. STATIC ANALYSIS TOOLS - CHURN High method and class churn has been shown to have increased bug and error rates ...
25. 8. STATIC ANALYSIS TOOLS - REEK Reek is a tool that examines Ruby classes, modules and methods and reports any code smells it finds.
26. 8. STATIC ANALYSIS TOOLS - REEK You could quickly look for what code smells there are in a bunch of files, just to see how s(nky the code base is:
27. 8. STATIC ANALYSIS TOOLS - CODE_METRICS rake stats is great for looking at sta(s(cs on your code, displaying things like KLOCs (thousands of lines of code) and your code to test ra(o.
28. 8. STATIC ANALYSIS TOOLS - CODE_METRICS
29. 8. STATIC ANALYSIS TOOLS - RUBOCOP RuboCop is a Ruby sta(c code analyzer. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide.
 

30. 8. STATIC ANALYSIS TOOLS - RUBOCOP Again we could get all the severi(es for researching purposes:
31. 8. STATIC ANALYSIS TOOLS - UNUSED A command line tool to iden(fy unused code.
32. 9. UNDERSTAND YOUR TESTS Try the following: Squint test your files Iden(ty the Subjet/System Under Test (SUT) Understand the test setup and dependencies And: Find out the test coverage Single Responsibility Principle also applies to tests Further reading: There are Test Smells
33. 10. EXTRACT FEATURES OUen (mes changing code will get just hard, consider extrac(ng features into a new app When: Lack of documenta(on or outdated Single test containing mul(ple SUT Low coverage Hard test setups Slow test suite How: Create a high level collabora(ve test suite, check Specifica(on by Example Bring enough code to make tests pass, iterate
34. 11. ADOPT A FEW CORE IDEAS Curiosity Assess risk Fear and courage Ensure safety harnesses Ask ques(ons Experiment Take notes The boy scout rule
35. ACKNOWLEDGEMENTS @chischaschos Uncle Bob Working Effec(vely with Legacy Code
36. THANK YOU twicer: @zazvick github: @vicmaster email: victor.velazquez@magmalabs.io