This document discusses strategies for working with legacy code. It defines legacy code as existing code that may be old, use outdated patterns, or obsolete frameworks but is still in use. It emphasizes that legacy code is not inherently bad if it is working and providing value. When refactoring legacy code, it recommends communicating with peers and business stakeholders, limiting scope, making a plan, using tools like coding standards and tests, and automating processes. The main message is that legacy code should not always be refactored and to focus on understanding the code and business value it provides.
14. @asgrim
"Legacy"
Can mean...
● Old code
● Code that uses outdated patterns
● Obsolete (but still used)
● Difficult to maintain
● Uses old frameworks / libraries
● Fragile / untouchable
● Expensive to replace
15. @asgrim
"Legacy"
Can mean...
● Old code
● Code that uses outdated patterns
● Obsolete (but still used)
● Difficult to maintain
● Uses old frameworks / libraries
● Fragile / untouchable
● Expensive to replace
● Working code
● Code that (usually) still provides VALUE
● Code written an hour ago
16. @asgrim
"Code can be in two states:
in production
...or almost useless"
- Srdjan Vranac (@vranac)
65. @asgrim
To summarise...
"Legacy" !== "bad"
● It's just "existing code"
● If it's in production, it usually produces VALUE
How to tackle existing codebase?
● You don't always need to refactor
● Communicate - peers & business
● Produce documentation
● Learn to really READ code!
● Determine what produces VALUE (both business value + developer experience)
● Use tools to help improve code quality
● Characterise critical functionality with tests
● Build up your "test pyramid"
● Automate all the things!