Nano Refactorization

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."

This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004