Search a title or topic

Over 20 million podcasts, powered by 

Player FM logo
Artwork

Content provided by iteration podcast, John Jacob, and JP Sio - Web Developers. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by iteration podcast, John Jacob, and JP Sio - Web Developers or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://staging.podcastplayer.com/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Principles in Refactoring

42:51
 
Share
 

Manage episode 230421565 series 1900125
Content provided by iteration podcast, John Jacob, and JP Sio - Web Developers. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by iteration podcast, John Jacob, and JP Sio - Web Developers or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://staging.podcastplayer.com/legal.

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
  continue reading

78 episodes

Artwork

Principles in Refactoring

iteration

113 subscribers

published

iconShare
 
Manage episode 230421565 series 1900125
Content provided by iteration podcast, John Jacob, and JP Sio - Web Developers. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by iteration podcast, John Jacob, and JP Sio - Web Developers or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://staging.podcastplayer.com/legal.

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
  continue reading

78 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Copyright 2025 | Privacy Policy | Terms of Service | | Copyright
Listen to this show while you explore
Play