three principles to bring your legacy code into the future
Abstract
- Rewrite or refactor? Rewrite only with test coverage.
- Old bugs need to be added to the rewritten system.
- How to increase test coverage?
- Add tests for current behavior.
- To understand legacy code, use a technique “Scratch Refactoring”:
- Learn through refactoring.
- Make experiments.
- Revert everything.
- Use descriptive test names.
- Keep relevant stuff together, hide irrelevant stuff.
- Delete methods that do nothing useful, keep it simple.
- Hard-to-mock dependencies (e.g. current time, database, external systems).
- Declare dependencies as parameters.
- Separate domain and infrastructure to simplify testing.
- Use inverted TDD.
The speaker promotes the book “Working effectively with legacy code”.
Reviews
Why did I want to read/watch this? We are always maintaining legacy projects. Even a few months old project can be considered legacy when you don’t really understand the project structure, what the classes are doing, etc…
What did I get out of it? Most of the advice are quite general. However, there’s one technique that I find quite useful is the “Scratch Refactoring”. It may be a good and quick way to understand some code.