$cd ~What I Learned from "Working Effectively with Legacy Code"
Contents
The page image is mind map made by myself. (Apologize you need to enlarge the picture if you want to take a look)
How to entering a legacy system?
Common pain points
- Hard find where to add new features
- Mental overload when reading the code
- Hard to identify the reported issue belongs to bug or feature
- Hard to find the root cause when error happened
- No tests existed
The project structure is lost
- Sketch the concept first, don’t jump into the code directly
- Figure out the responsibility of the system
The intent of the functions or methods are ambiguous
- Give the comment tag with corresponded responsibility to the lines of code
Scratch Refactoring
- Even there is not testing, it is still recommended to create a new branch to do refactor
- By extracting the method and moving variables, you can avoid to checking the code again
- If the refactored code can work correctly then you can make sure you understand the code correctly
How to deal with the system with too many API calls?
What are the pain points?
- Hard to writing tests
- We often think there only few of self business logics so no need to write the tests
- If we writing the tests would cause the side effects
Steps for the problems
- Write a brief description for the code
- Separate the code responsibility
- Draw the design with class diagram
Strategies for interacting with API call
Wrapping
- A higher level abstraction interface to the application
- Let us can fake the method during test. (OOP support virtual method)
Responsibility-based extraction
- You want to completely separate out the dependency from API calls
The difference between high level test and low level test
High level test
- Information for telling you the system currently break the change
Low level test
- Information for telling you why the system break the change
Avoid reorder and breaking apart expression while refactoring
- Instead, do extraction from high level piece and break dependency at the same time