Working Effectively with Legacy Code
- 1. Working effectively with legacy code Workshop 2017-04-10
- 2. About me Audrius Kovalenko | @slicklash NOT Software Archaeologist Just a developer
- 3. What’s a legacy code?
- 4. What’s a legacy code? In production Functional Business value Must keep working Outdated Expensive and difficult changes High cognitive load No tests etc.
- 5. Legacy Code What’s a legacy code?
- 6. “A complex system that works has evolved from a simple system that worked. Maintainability is a hard problem system growth is organic
- 7. “A complex system that works has evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to work.” Gall’s law Maintainability is a hard problem system growth is organic
- 8. Maintainability is a hard problem emergent design is hard solution initially looks like an attractive road with flowers...
- 9. Maintainability is a hard problem emergent design is hard https://martinfowler.com/bliki/AntiPattern.html solution initially looks like an attractive road with flowers... ... but further on leads you into the maze of monsters
- 10. “Any piece of software reflects the organizational structure that produced it.” Conway's law Maintainability is a hard problem imposed things are hard to escape
- 11. QUALITY TIME COST expensive late bad quality scope change Maintainability is a hard problem project management triangle
- 12. QUALITY TIME COST expensive late bad quality scope change Maintainability is a hard problem project management triangle Brooks’s law Parkinson's law Hofstadter's law
- 13. Roots of evil complexity “The number of objects an average person can hold in working memory is about seven.” Miller's law 7±2
- 14. Roots of evil complexity “The number of objects an average person can hold in working memory is about seven.” Miller's law 7±2 Complexity limits what we can do
- 15. Roots of evil complexity How easy is it to change a single element? How does the change propagate?
- 16. Roots of evil complexity dumb dumbunder-engineering over-engineeringsimple complex
- 17. Roots of evil complexity quick hacks spaghettiduplicates and globals inception layersseparation composition
- 18. Roots of evil complexity “Simple is better than complex. Complex is better than complicated.” from The Zen of Python, by Tim Peters https://www.python.org/dev/peps/pep-0020/
- 19. Roots of evil complexity measuring complexity with https://www.sonarqube.org/
- 20. Roots of evil complexity “Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.” E. W. Dijkstra
- 21. Roots of evil entropy How much information does a change carry? What does constant high entropy mean?
- 24. Roots of evil entropy High entropy + frequent releases = bad combination 2.0.0-beta.0..1..2..3..4..5..6..7..8..9..10..11..12..13..14..15..16..17.. 2.0.0-rc.0..1..2..3..4..5..6..7.. 4.0.0-beta.0..1..2..3..4..5..6..7.. 4.0.0-rc.1..2..3..4..5..6..
- 25. Roots of evil entropy The more parts of the system you need to modify the harder it is to implement that change.
- 26. Roots of evil entropy Symptom of leaky abstractions and tightly coupled dependencies The more parts of the system you need to modify the harder it is to implement that change.
- 28. Approaching legacy code systematic approach Examine the system Identify pain points and red flags Create a master plan Build a toolbox
- 29. Examine the system know your system “Chainsaw is supposed to be loud.” Understand the system and know what's usual and what's not.
- 30. Examine the system know your system Enumerate all components Identify critical parts Learn what not to do Learn whom to seek if you did it anyway
- 31. Examine the system know your system
- 32. Pain points and red flags start asking for what’s wrong List down everything what gives you pain
- 33. Pain points and red flags start asking for what’s wrong No domain expert is available Memory bound code Poor practices 3rd party locked-in No tests and CI No automation Big feedback delays etc.
- 34. Pain points and red flags Agile vs agility
- 35. Create a master plan goals and targets Goals give direction and focus (what not to do)
- 36. Create a master plan goals and targets Goals give direction and focus (what not to do) Relevant Specific Achievable Measurable Time-bound
- 37. Create a master plan goals and targets Challenge your limits Think outside the box Make X great again Chakka-Chakka! Bad goals
- 38. Create a master plan goals and targets People with realistic goals apply more effort and perform better, and people with unrealistic goals pull back.
- 39. Create a master plan goals and targets Focus on addressing pain points
- 40. Build a toolbox good plan is half the battle Competence Backups VCS Automation Safety net Playbook and Exercises Documentation Contingency plan
- 41. Dos and Don’ts create value Reduce complexity and guesswork Keep entropy low Track changes Write clear commit messages Deploy often Invest in automation Focus on preventing fire not putting it off
- 42. Dos and Don’ts When Do NPR rule fixing a defect adding new feature refactoring the necessary be pragmatic the right thing
- 43. Dos and Don’ts fixing what’s not broken Refactoring because it’s not your way is a waste.
- 44. Dos and Don’ts fixing what’s not broken Refactoring because it’s not your way is a waste. Don’t touch components you are not going to change.
- 46. You are not ready for a big refactoring
- 47. Books
- 48. Resources Catalog of Refactorings https://refactoring.com/catalog/ Legacy Code Rocks! http://legacycode.rocks/ Methods & Tools http://www.methodsandtools.com/
- 49. QA