The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

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

Page 1 of 5  >>


Martin Fowler, chief scientist at Thoughtworks, Inc. and author of numerous books on software design and process, talks with Bill Venners about refactoring, testing, and design.

Over the last decade, Martin Fowler pioneered many software development techniques in the development of business information systems. He's well known for his work on object-oriented analysis and design, software patterns, Unified Modeling Language, agile software processes (particularly extreme programming), and refactoring. He is the author of Analysis Patterns (Oct. 1996), Refactoring (June 1999; coauthored with Kent Beck, et al.), UML Distilled (Aug. 1999; with Kendall Scott), Planning Extreme Programming (Oct. 2000; with Kent Beck), and the soon to be released Patterns of Enterprise Application Architecture (Nov. 2002), all published by Addison Wesley.

In this six-part interview, which will be published in weekly installments, Fowler gives his views on many topics, including refactoring, design, testing, and extreme programming. In this initial installment, Fowler makes the business case for refactoring and testing, and describes the interplay between refactoring, design, and reliability.

Bill Venners: Define refactoring.

Martin Fowler: Refactoring is making changes to a body of code in order to improve its internal structure, without changing its external behavior.

Bill Venners: If refactoring doesn't add features or fix bugs, what is the business case for it? How do you justify refactoring?

Martin Fowler: Refactoring improves the design. What is the business case of good design? To me, it's that you can make changes to the software more easily in the future.

Refactoring is about saying, "Let's restructure this system in order to make it easier to change it." The corollary is that it's pointless to refactor a system you will never change, because you'll never get a payback. But if you will be changing the system—either to fix bugs or add features—keeping the system well factored or making it better factored will give you a payback as you make those changes.

Page 1 of 5  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use