Xp Refactoring Faq

From XpFaq

I hope they won't mind my butting in with a bunch of sample questions and answers here. PhlIp, feel free to alter the style or content to fit better in your larger-scale project... -- GarethMcCaughan

The rule is

A: Someone had to actually ask and answer it - make nothing up.
B:Any discussion must be off page - that would break the purpose for A.

Minor edits or insertions permited for dramatic exposition.

Q. What is this "refactoring" business anyway?

Refactoring is changing code structure without changing its function, especially when it's done in order to make it clearer or simpler or easier to modify.

UnitTests can't sample structure very well, but they pin down the functionality.

XP advocates refactoring mercilessly: in other words, when you see something, anywhere in the code, that could be made clearer or simpler (an ill-named method, two places where the same code occurs, ...) or something that needs to be refactored for you to make the next change you want to make, you should change it right away. The idea is that starting with anything that works and refactoring it as problems arise will produce well-designed code without the need for lengthy design at the start of the project.

Q. Isn't that just the same as tidying up your code?

Not quite. Refactoring is more precisely defined than that; a change that alters the functionality of the code isn't a refactoring, even if it makes things tidier. But it's not so very different.

Q. Isn't it terribly rude to change someone else's code?

Perhaps, but in XP all the code is collectively owned.

Q. Isn't it terribly dangerous to go fiddling with code so freely?

It would be if it weren't for two things.

In XP, there should always be a good suite of unit tests, which should catch almost all the mistakes. Remember that all the unit tests run every time you change anything.
Many of the more common refactorings can be carried out in ways that greatly reduce the chance of error. See RefactoringImprovingTheDesignOfExistingCode.

Q. Where can I find out more about this?

In MartinFowler's book, RefactoringImprovingTheDesignOfExistingCode.

Q. The verb is to refactor. Is the noun form a refactoring or is it a refactor?

It is a refactoring. Was it your think that refactor would be consistent with English speak and write?

Q. Why did MartinFowler invent the word "refactoring", when a previously-published book, "LargeScaleCppSoftwareDesign" by JohnLakos, used the word "factoring" for the same kind of behavior-preserving transformations of software?

Maybe because he wanted to emphasize its ongoing nature? It embeds the idea of evolutionary design in the name itself. Think about the connotations of, "This code is well-factored." It sounds almost like it is set in stone, ready for the ages. "This code is well-refactored." says, "Hey... I didn't get it perfect up front, but who cares because it's perfect now."

(Actually the term "well-factored" in descriptive use applies here. The process of "refactoring" is to "factor again" but this time to arrive at "well-factored" code.)

Also please note. Martin Fowler did not invent the term refactoring. As far as I can determine, the term was coined by a member of RalphJohnson's UIUC Smalltalk group somewhere around 1990. The earliest reference is in a paper by RalphJohnson and BillOpdyke ("Refactoring: an Aid in designing application frameworks...") submitted to the Proceedings of the Symposium on Object-Oriented Programming Emphasizing Practical Applications (SOPPA) in 1990. The next reference to the term I can find is in the title of the dissertation by BillOpdyke "Refactoring Object oriented Frameworks". That was submitted in 1992. I seem to remember several articles in the SmalltalkReport mentioning the term between 1993 and 1997. JohnLakos published his book in 1996. As to why he didn't use the already accepted term refactoring, well your guess is as good as mine...

Be sure to see CategoryRefactoring and WikiPagesAboutRefactoring too.