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