http://rubyrogues.com/178-rr-book-club-refactoring-ruby-with-martin-fowler/
podcast-rr-178-refactoring-with-martin-fowler#make-the-change-easier1 "What would this code need to look like to make the changes that I'm about to make be simple" podcast-rr-178-refactoring-with-martin-fowler#make-the-change-easier1
Martin calls it preparatory refactoring here: preparatory refactoring in talk-workflow-refactoring
Martin Fowler's refactoring... so incremental. BOLT. Lock in your passing tests... need very easy alias, and need to idealize your history after-the-fact. Never get stuck debugging... rather, use your isolated tests for debugging some tiny issue.
podcast-rr-178-refactoring-with-martin-fowler#small-steps1 Avdi: "And I think that's for me one of the most interesting parts of reading this book, is just realizing how granularly these individual refactorings are broken down. Not just that the refactorings as a whole are relatively short changes, but also that they're broken down into very small steps." podcast-rr-178-refactoring-with-martin-fowler#small-steps1
podcast-rr-178-refactoring-with-martin-fowler#no-longer-use-debuggers1 JESSICA: I liked that part of the book where it talked about we're tempted to go to the debugger when there's a problem. But if you go into the debugger, you don't know how long it's going to take to find the problem. But if you back up, you know exactly how much time it's going to take to back up. And the time you put in is the maximum time you can lose. So, the time lost is constrained by backing up. And it's completely open-ended if you get into the debugger.
MARTIN: Yeah. In many ways, I think as refactoring and test-driven development which obviously goes very close with refactoring, is all part of the plot to make us no longer use debuggers. podcast-rr-178-refactoring-with-martin-fowler#no-longer-use-debuggers1
podcast-rr-178-refactoring-with-martin-fowler#sacrificial-architecture1 "And actually, the post I was working on this morning which hopefully will be out by the time this episode goes live, is on what I'm referring to as sacrificial architecture, the idea that sometimes it's perfectly okay to say, "I'm going to build this system," particularly in context of things like startups but I suspect in many other contexts as well, "and I'm not going to worry about what happens if it gets 100,000 users, because I'm going to build it with the expectation that once it gets up to 10,000 users, I'll throw it away and rewrite it from scratch." And we don't tend to think of software deliberately written to be thrown away once you get beyond a certain size.
But often, it actually makes sense because to build a system and try to put too much scale ability to it early on, that imposes a lot of extra baggage that is going to be a problem if you're still trying to figure what on earth the system ought to be in the first place. And you look at a lot of successful website outfits, they did this scratch, rewrite, throwaway business multiple times. EBay is an example. Twitter's an example. Amazon's an example. It's regular practice at Google. But what we're not yet ready enough, not yet got enough, is that sense of when do I make that cut between rewrite and refactor. And unfortunately, it's like so many of these things, it's experience and it's not something that I can find easy to describe at this point." podcast-rr-178-refactoring-with-martin-fowler#sacrificial-architecture1
testing-concept-preparatory-refactoring
testing-concept-reduced-need-for-debuggers