Big Refactorings

What makes a refactoring big? The number of RefactoringMove's it requires? The amount of work done? The effects?

SubstituteClass can be done at one sitting for small to medium system, but it does build upon other refactorings. More importantly, it can be used to change the way application abstractions are understood, but then so can RenameClass. This is true

A refactoring is big if you have to make more than 30 seconds worth of changes before you can run the unit tests.

According to this definition, all refactorings in C++ are big. In fact, most refactorings in Smalltalk without the RefactoringBrowser are big. I would make that be at least 5 minutes, or even an hour. -- RalphJohnson

: Working in C++, it was often the case I could implement an entirely new feature in less than five minutes, let alone do microrefactorings (like renames, which was a simple grep, or method extraction, etc.). I'm not sure why C++ would make all refactorings long. Could you explain please? -- SunirShah?

Smallish refactorings are a greedy approach and can only locally optimize. Occasionally, you may need to shake the system in order to get to the global minimum complexity. -- SunirShah?

I believe this turns out not to be the case. Refactorings are invariably reversible: therefore not all refactorings optimize, let alone locally. A question to address is whether all BigRefactorings can in fact be done by a series of small refactorings. If they can, then there is no refactoring that cannot be accomplished in little bites equalling one's [small] attention span. --RonJeffries

Reversibility does not exclude the possibility of finding the optimally simple solution. Mathematically speaking (zzzzz...), imagine a computer program that has a set of equivalence productions that it can apply to an arbitrary string in a given grammar. The program applies those productions on a given string, returning the shortest string after a given time. (The inductive bias being fewer symbols is simplest.) I'm afraid I don't understand how refactorings don't optimize. -- SunirShah?

Earlier this year, DaveMuirhead and I extracted a framework layer out of the FoodSmart application that we had developed during the previous year, refactoring the application as we went to use the extracted framework layer (whose classes were moved to different packages, and renamed in some cases). Along the way we did some other minor refactorings, but on the whole it was basically an extraction exercise. The original application had 304 types (Java classes and interfaces). The extracted framework layer ended up with 147 types, and the refactored application was left with 156 types. It took us about 15 man-days, spread out over several weeks due to other priorities, to do the job. At the end we did a thorough use case test of the application, and found the exercise to be behavior-preserving. We didn't keep many refactoring notes as we went through the process, but the main refactoring move we were using was MoveClassToDifferentPackage? - a move not documented in RefactoringImprovingTheDesignOfExistingCode. One of our main goals throughout the exercise was to minimize compilation dependencies among packages, in the spirit of PartitioningSmalltalkCodeIntoEnvyDeveloperComponents. This was certainly the biggest refactoring I've ever done. --RandyStafford

See DeprecationRefactor.

CategoryRefactoring.

EditText of this page (last edited July 18, 2002)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004