Refactoring can be dangerous, to your program and to your health. In this episode we discuss techniques to enable safe and healthy refactoring methods.
Show Notes
- Story time
- (Thomas) I used to have delusions of grandeur about my refactoring ability
- Austin recent project
- Purpose: to make the code better
- The challenge, how to do it so that:
- You don’t break things unintentionally
- You don’t get mired in the details and unable to move forward
- It doesn’t take forever
- Method
- Code is the way it is for a reason
- Incremental
- Keep a working version
- Develop in parallel
- Contracts
- Don’t break contracts until you have a working replacement
- Contracts are:
- between input and output
- functions
- components
- interfaces
- libraries
- Bottom-up
- Don’t worry about code duplication until the end
- Avoid “second-system” effect
- Try to understand why the original system was created the way it was, don’t assume you know better, even if you do
- Story time
- I’m working on a large refactoring project involving the inventory system
- No down-time, must be 100% accurate
- I’m building it:
- In parallel with the existing system until it proves to be a worthy replacement
- Incremental, developing and deploying many smaller pieces along the way
- NOT as one large project that gets deployed all at once
Support the show
