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.
John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.
JP: This is part 2 of chapter 6, "While you are coding". Last week we talked about pragmatic practices while you are coding.
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?
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?
Test ruthlessly. Don't make your users find bugs for you.
HOT QUOTE ALERT
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.
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