Sponsored Link •
Bill Venners: To explain when to apply refactorings, you write in your book Refactoring: "Rather than appealing to some vague notion of programming aesthetics (which frankly is what we consultants usually do), I wanted something a bit more solid."
I'm curious to what extent you think aesthetics matter. In most of my experience, I've had to work with an already existing body of code. The code is usually poorly designed, and as a result, very painful to work with. I would really appreciate a good design that isn't so painful to work with. So aesthetics matter to me at least in the sense that well-designed software makes my work life more enjoyable.
Martin Fowler: I wrote that about aesthetics in discussing when you apply refactorings. To some extent, the situations I describe in the refactoring guidelines are fairly vague notions of aesthetics. But I try to provide more guidance than just saying, "Refactor when the code looks ugly." I say, for instance, that duplicated code is a bad smell. I say that long methods are a bad smell. Big classes are a bad smell.
Many bad smells can be very superficial. When you look at a program, it is amazing how often focusing on some superficial element, like a 100-line method, can help you improve a design.
In the course of refactoring a 100-line method, you find that some bad design decisions were made about responsibility allocation. You couldn't spot the bad design decision just by looking at the method, but you could spot that the method was 100 lines long. And the superficial problem led you to the rest of the mess.
Bill Venners: I once worked on a project where there was an 11-page while loop.
Martin Fowler: That's appalling.
Bill Venners: And it was still 11 pages after our 6-month task force to stabilize the software, because we were afraid to change it.
Martin Fowler: That itself indicates the 11-page while loop's bad design, because if you're afraid to change something it is clearly poorly designed.