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