Refactoring, Testing and Wizard Wizardry

Episode Summary

This week we continue our series on the Pragmatic Programmer covering Chapter 6 (part 2) About refactoring, designing to test, and the pitfalls of using wizards if you don't understand all of the code they produce.

Episode Notes

Chapter 6 - Pragmatic Programer:

John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

Small talk - We were off for the 4th - yada yada yada

JP: This is part 2 of chapter 6, "While you are coding". Last week we talked about pragmatic practices while you are coding.

Part 2

Tip 47 Refactor Early, Refactor Often

Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem

Time pressure is often used as an excuse for not refactoring. But his excuse just doesn't hold up: fail to refactor now, and there'll be far greater time investment to fix the problem down the road - when there are more dependencies to reckon with. Will there be more time available then? Not in our experience


Keep track of the things that need to be refactored. If you cna't refactor something immediately, make sure that it gets placed on the schedule. Make sure that users of the affected code know that it is scheduled to be refactored and how it might affect them.

Martin Fowler's tips for refactoring

1.) don't try to refactor and add functionality at the same time
2.) make sure you have good tests in place before you begin refactoring
3.) take short, deliberate steps

What's your tolerance for pain?

Tip 48 Design to Test

Start thinking about testing before you write a line of code

John: If your tests are hard to write - the design of your system is probably inelegant. It's a "design smell" if you are thinking - how the hell am I going to test this?

Tip 49 Test Your Software, or Your Users Will

Test ruthlessly. Don't make your users find bugs for you.


Testing is more cultural than technical: we can instill this testing culture in a project regardless of the language being used.

John: Related: Re-create bugs in tests when debugging. every. time.

Tip 50 Don't Use Wizard Code You Don't Understand

Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project

We are not against wizards [...] But if you do use a wizard, and you don't understand all the code that it produces, you won't be in control of your own application. You won't be able to maintain it, and you'll be struggling when it comes time to debug


John: Jesus Castello - Ruby Guides on YouTube