The Artima Developer Community
Sponsored Link

Refactoring with Martin Fowler
A Conversation with Martin Fowler, Part I
by Bill Venners
November 4, 2002

<<  Page 4 of 5  >>

Advertisement

Refactoring and Change

Bill Venners: You write that you refactor not because it's fun, but because "there are things you expect to be able to do with your programs if you refactor that you just can't do if you don't refactor." Other than change, what can you do with your programs if you refactor that you can't do if you don't refactor?

Martin Fowler: Change is the driving reason. We constantly have to change software—living software at least. Refactoring is about improving the design, and we want a good design so we can change it more easily. Refactoring is similar to things like performance optimizations, which are also behavior- preserving transformations. But the kinds of moves you make in performance optimization are different than refactoring, and the overall process is slightly different, because optimizations should be driven by profiling.

Bill Venners: So refactoring means making changes that don't add or change functionality for clarity, so I can easily make changes in the future. Performance optimization is similar in that I make changes that won't change the functionality other than its timing.

Martin Fowler: Right. They're similar, but I think sufficiently different to warrant different names.

Refactoring and Design

Bill Venners: You wrote in Refactoring: "Refactoring helps improve the design of software." How does refactoring improve the design?

Martin Fowler: I don't think I can give you a general answer, but you can look at the individual refactorings and the way they improve the design. The Extract Method refactoring improves the design by taking a long, convoluted method and breaking it down into smaller methods. What's left of the old method then reads like documentation: a list of things you do by calling the smaller methods.

Every refactoring has some element of improving a design. Many are context specific. Many refactorings come in opposing pairs. For example, if a method does nothing more than what the body of code says it's doing then you would inline it. Inline Method is the opposite of Extract Method. Many times context determines whether to apply one refactoring over the other.

Refactoring and Finding Bugs

Bill Venners: You also claim in Refactoring that refactoring helps you find bugs. How does refactoring help you find bugs?

Martin Fowler: I think refactoring helps you find bugs in a couple ways. Sometimes as you make your program easier to understand, the bugs just leap out at you. You'll be refactoring and you'll say, "Hang on, what happens if so and so?" I have found bugs that way, and so have many other people. Refactoring suddenly makes things clearer, so suddenly you can see a bug exists.

Refactoring also helps you find bugs when you're trying to fix a bug in difficult-to- understand code. It's often easier to refactor that code while you're debugging it, so you can easily find where the bug is. By cleaning things up, you make it easier to expose the bug.

Often a good debugging technique is to write focused unit tests around the area where the bug is. Of course that has the advantage that you're not just improving your understanding, but you're also building up the test base, which implies that things will stay fixed.

<<  Page 4 of 5  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us