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

If you are using a good IDE like EclipseIde, its AutomatedRefactoring support (inspired by the SmallTalk RefactoringBrowser) allows for six hours of refactoring (rename, search, change method signatures, etc) to be boiled down into one RightClick? -- JevonWright?

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

I don't think the question is whether refactorings optimize; they clearly do. The more important question is, can a series of small refactorings optimize as completely as a single BigRefactoring?. -- JevonWright?

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.

I find there are three categories of refactoring:

Intra-source refactoring, things like moving or renaming privately defined symbols, etc. The nature of this category of refactoring necessarily restricts the scope of change to just the one source file. I think this obviously falls under the category of a SmallRefactoring?.
Inter-source refactoring, where publicly available details change. Perhaps you're renaming a publicly defined API procedure, or somehow altering an abstract data type in some previously incompatible fashion. Within this category, we have:
- Dual-source refactoring, where the scope of the change remains confined to two source files. This remains in the realm of SmallRefactoring?, because the mental overhead isn't all that great compared with intra-source refactoring.
- Everything else, where the scope of the change involved spans across three or more source files. The larger the scope, the more difficult the refactoring. These usually imply architectural overhauls, which itself could well mean altering unit tests to reflect the new architecture as well.

--Samuel A. Falvo II

Counting files modified is one measure, I suppose. But I tend to understand the 'scope' of really large refactoring based on the number of distinct 'projects' that must be adjusted, especially across ownership boundaries.

CategoryRefactoring.