A
NanoRefactorization is a very small Refactorization that changes the system just so much that more
NanoIncrements can be implemented.
Just as a series of
NanoIncrements leads to a large increment, a series of
NanoRefactorizations leads to a large Refactoring.
Since you can finely adjust how many
NanoRefactorization you apply,
NanoRefactorizations are better tuned with the
YouArentGonnaNeedIt and
DoTheSimplestThingThatCouldPossiblyWork patterns than are single Refactorings.
--
TomHoulder
In fact, since
DoTheSimplestThingThatCouldPossiblyWork applies to refactoring,
ExtremeProgrammer's generally do their refactoring consistently with the Nano idea. --
RonJeffries
My problem with a word like
NanoRefactorization is that refactorings should always be small. The biggest refactorings are things like "reuse some functionality by delegation instead of by inheritance" and "break a class into two pieces". If you don't have very good tool support and have a large system then these refactorings can take a long time. However, in Smalltalk, they never take more than a few hours, and the
RefactoringBrowser makes them go even faster.
Refactorings should be so small that if you run your unit tests and find that something doesn't work, it should be trivial to find the problem.
--
RalphJohnson
Perhaps this is an example of a "nano-refactoring:"
"I don't like the name of this local variable in this method. I'll change it from 'myString' to 'strErrorMessage'. <Does search and replace within the method.> There. Now a quick run of the
UnitTests, and I'll be on my way."
CategoryRefactoring