What Refactoring Means Discussion

Don't you want to ask WhatIsRefactoring?

Not particularly.

Maybe I don't understand refactoring, but what's the difference between "refactoring" as used on this page and the one on WhatIsRefactoring?

This was copied from CoreXpDependencies. There the Assertion was made that:

SimpleDesign ---> (depends on) Refactoring. The only reason you can DoTheSimplestThingThatCouldPossiblyWork is that you know you can always refactor it later if the problem turns out more complicated than it seems.

This relationship is backwards. Refactoring is not a method for adding functionality. It is a way to maintain functionality while simplifying the code.

You've misunderstood the point. In fact, a refactoring is (according to Johnson) any behavior-preserving source code transformation. This could involve adding functionality or moving the code to make it easier to read, maintain, or extend. The assumption here is that you don't need to plan for the most obscure possibility in the beginning because you know that if it becomes necessary you can always refactor the code to add it in while maintaining the existing functionality. However, I will grant that the relationship might be bidirectional.

I'm not sure who "Johnson" is, but the usual definition of refactoring is the one provided by MartinFowler in RefactoringImprovingTheDesignOfExistingCode ("Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." page xvi). The point of refactoring is to not change functionality. The dependency is SimpleDesign is dependent upon Refactoring. It has nothing to do with DoTheSimplestThingThatCouldPossiblyWork.

The Johnson I'm referring to is RalphJohnson, who originally coined and defined the term refactoring. MartinFowler, BillOpdyke, KentBeck and JohnBrant (notice the relationship here?) all use Ralph's definition. Martin popularized the term in his book only after Ralph and his students (and the rest of the Smalltalk community) had been throwing it around for years. And no, it DOES have something to do with DoTheSimplestThingThatCouldPossiblyWork. I'll try to work this out again. What we are fighting is the urge that MANY OO developers have which has been expressed as PrematureGeneralizationIsEvil.

The problem is this. Given the choice, many developers will work themselves into a design frenzy. They will add all sorts of bells and whistles to code because it's neat, not because the requirements for TODAY call for it. Or they will labor long and hard to work out the most general of all possible solutions to a problem (with Interfaces for every class, and overloaded parameter sets for every method) just because someone MIGHT someday in the future find a need for it. This is the design equivalent of AnalysisParalysis. We saw that in Smalltalk where every big company started by initiating a huge project to build a "Framework" (in the absence of requirements, of course) before any real projects ever began. We saw the same thing in C++. The only reason we didn't see it in Java is that most big Java projects were started by old farts with experience in one of the two previous languages who had seen those sort of projects tank, big time.

So the relationship here is that you don't allow your programmers to do that! Solve today's problems today. Since in all probability YouArentGoingToNeedIt, only DoTheSimplestThingThatCouldPossiblyWork. If code is not strictly called for by a UserStory, don't write it. If another UserStory arises tomorrow that requires you to rewrite today's code (usually to add functionality, but which may require a REFACTORING of the existing code in order to accommodate the new functionality), that's tomorrow's problem. The point is that if you allow yourself the time to refactor, then solving the problem when it occurs will be enough. You don't have to worry yourself into a frenzy today. As it's been so well put: Do not worry about tomorrow; for tomorrow will care for itself. Each day has enough trouble of its own.

The apparent conflict is between the following two definitions:

1) "a refactoring is any behavior-preserving source code transformation. This could involve adding functionality ..."

and

2) "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure."

One reading of the first is that it allows the addition of functionality as long as the original functionality is preserved, while the second specifies no changes in functionality. In practice, however, adding functionality is often what brings about the need to refactor. A new UserStory arises, functionality is added on, and the system is no longer well factored, so a refactoring is in order. We DoTheSimplestThingThatCouldPossiblyWork twice, and allow time for refactoring to preserve a maintainable code base.