It’s easy to look at work that came before you and decide it’s no good and that you can do better. This is the wrong attitude. It will lead you down a very dangerous path.
7 Key takeaways for refactoring legacy code
- Never judge legacy code or change it until you’ve taken the time to fully understand it.
- Sequence diagrams are your friend.
- Prefer small, incremental improvements over wholesale re-writes or changes.
- Each change should attempt to leave the code a little better off than it was when you found it.
- If you need to make big changes, make a business case and get approval first.
- When adding new features, try to “go with the flow.”
- If you need to take the code in a new direction, isolate your changes and use the Adapter Pattern to integrate.
Questions to ask before refactoring code
- What is my goal in doing the refactor project?
- How will I know if I’ve accomplished the goal?
- What will be different if I accomplish the goal?
- How much time and money should be invested in this goal?
- What is the ramifications if I postpone the refactoring project for six months?
Source: Marcus Blakenship
Characterisation Tests
These are useful for nailing down the behavior of the existing code. They are different from test driven tests - revealing intent is not necessarily a primary objective.
Refactoring Articles
Martin Fowlers Catalog of Refactorings
How to conque legacy code
Shims, Jigs, and other woodworking concepts to conquer technical debt
Refactoring Code Base Links
Below are a set of links to code bases that are useful for refactoring exercises.
Gilded Rose Kata
Legacy Code Retreat Trivia Game
Rob Meyers C# Refactoring Lab
