Chapter 2 Principles in Refactoring
A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.
- Define Refactoring
- “If someone says their code is broken for a couple days while they are refactoring =, you can be pretty sure they aren’t refactoring.
- Adding Features Vs Refactoring
Why should we refactor?
- Code rot - overtime the code decays - rushed or poorly executed changes
- Regular refactoring helps keep things in shape
- Makes things easier to understand
- (Delegating issues in clean codebase vs rough)
- Refactoring helps find bugs
- Refactoring helps us work faster long term - cleaning your workspace
- Over time adding new features is easier
Getting buy in for refactors:
- Don’t tell your manager / client
- Build it into your estimates
- You are being paid for your expertise
- be confident in somewhat hiding the implementation. (Depends on your role)
When to refactor:
- Prepatory Refactoring
- Comprehension refactoring
- Long term refactor - Ech small change leaves everything is a still working state, not just “up to date”
- In code reviews
When to not refactor:
- If the code is working fine and it doesn’t need to be changed
- If it works like an API
- When it will slow down an essential new feature.
Legacy Code
Refactoring Tools for future episodes?
- Writing Ruby Gems
- Renovate Bot
Picks
- JP: Free Event Tickets
- John: Eero wifi router
