Rescuing Legacy Software from Impending Doom. Refactoring Stories from the Trenches

Dealing with an ageing code base is one of the hardest software engineering problems we face today. It is critical to solve this problem on the road to agility. In the past, software rewrites was standard practice when a company wanted to get rid of legacy software. Modern development practices and techniques has made refactoring a very popular first choice for software teams. In our experience we’ve seen how different teams attempted to systemically refactor their code with varying levels of success.

We will share the experiences of two software start-ups and a mid-size organisation. The speaker will explore case studies to guide attendees towards successful refactoring.

Topics covered in this talk will include
- effective refactoring methods (checklists),
- using test-driven development to support refactoring,
- when to do aggressive refactoring,
- common pitfalls and,
- classifications of technical debt to manage recovery.

We will also look at refactoring beyond the context of code, such as redesigning solutions and teams to improve agility.

Transcript

1. Rescuing legacy software from impending doom martin@nreality.com @martincronje
2. Refactoring stories from the trenches
3. Beyond process
4. Legacy code kills agility
5. What is legacy code?
6. “legacy code is simply code without tests.” Michael Feathers
7. “Legacy code is valuable code that we feel afraid to change.” J.B. Rainsberger
8. Do Product Owners see value in fixing it?
9. Typically they say… Not enough time We cannot afford it Business will close-down Just one more feature
10. So I went to speak to them...
11. Development teams are just as guilty
12. Why improve legacy code?
13. Craftsmanship Professionalism | Clean Code | Right Thing
14. Quality Maintainability and Extensibility
15. Economics
16. What is refactoring? What is our goal?
17. Improve the design of code to make it easier to work with. Joshua Kerievsky
18. Maximise Safety
19. Construction Refactoring
20. Structure Behaviour vs.
21. New code Code changes Solution wide TDD Refactoring Litter-Pickup Refactoring Comprehension Refactoring Preparatory Refactoring Planned Refactoring Long-Term Refactoring Refactoring workflows
22. Code changes
23. Cleaning up as we go
24. A lot is written about this
25. How would you approach it?
26. Golden Master Golden Master
27. Refactoring Activities Standards Readability Comprehension and Intent Separate concerns (Coupling) Consolidate responsibilities (Cohesion) Increased risk
28. Frequent small commits
29. Fix bugs separately
30. Don Roberts’ Rule of Three
31. Integrated tests are a scam
32. Run simulations! Tracer bullets.. Tracer bullet refactoring
33. Solution-wide refactoring
34. Handling major problems
35. From the trenches
36. Shanty Town What if this is the campsite?
37. We decided to refactor…
38. Problems in a real system •  Hardcoding everywhere •  Half-baked refactoring •  Unused code •  Duplication of code •  Code rewritten due to fear of extension •  No separation of concerns •  Namespaces not controlled •  Inconsistent external dependencies •  … and many more
39. Shouldn’t we just rewrite?
41. Backlog •  Consolidate repositories •  Standards •  Clean-code across solution •  Create scaffolding packages •  Get things that change together to live together •  Undo partial refactoring attempts •  Breaking up the silo
42. Activities •  Initiatives added to product backlog •  Public legacy code reviews •  Refactoring simulations on extreme messes •  20-40% allocation to fix the code •  Hack days to address specific problems
43. Small incremental changes Less than 5 days
44. Team structure
45. Team structure
46. Cohesion and Coupling applies to teams
47. In closing
48. Handling major problems
49. Cleaning up as we go
50. Economics
51. martin@nreality.com @martincronje