I wish this process was called 'factoring' and you had to be able to name the concept that was being isolated. Often 'refactoring' just means moving code around or isolating code for it's own sake. If a factor was properly isolated you shouldn't have to do that one again. Sometimes you choose different factors, but that's much less common.
I have a knee-jerk reaction when most people say "refactoring". In many cases they're talking about a different, arbitrary way to deduplicate an implementation, usually in a mindless/mechanical way. If you can't name the 'factor' that you're separating and that factor doesn't have business or conceptual cohesiveness, then you're just pushing bits around for someone else to want to do it differently. So now when someone says it, I always ask what do you propose to factor and why?
This exact thing happens when someone undertakes a refactoring without a clear concept of which factor is being separated. I now avoid the word refactoring and say I'm factoring 'thing'. If you'd factored it right the first time you wouldn't have to refactor it. That's not quite true sometimes things can factor further or choose a different factor first. Deduplication isn't factoring unless it's named and salient.
I often find myself (re)factoring when beginning work if the codebase is not in the shape (design rather than quality) that it needs to be in for the particular new features to fit well within it. The reason I wouldn't factor after implementation is that it should have followed a design that already identified the factors that are being separated.
Whenever there's continuous refactoring, the factors aren't so much known and decided at a high level, it's typically more an exercise of deduplication. If you can't name the thing (or why) you're factoring it's blind deduplication, which still has some value but is much lower. If someone says they want to refactor, I'll ask what's the factor and why. A system separated along well chosen seams allows things to naturally and easily fit in its design.
This is exactly my knee-jerk opposition to 'refactoring'. In many cases the cause for it isn't that the factor (seams along which the problem was separated) has changed, but rather the factor wasn't known at the time and was more like primitives composed without context or deduplicating patterns/machinery. Going top-down you'd be conceptualizing/picking/naming the factors as you go. Sometimes they change too but not at arbitrary points in layers of implementation, and this all happens sooner than later.
The traditional definition of refactoring is making well-understood, deterministic transformation of code from one state to another in a way that provably has no effects on the behavior. For example, Extract Method or Inline Variable are refactorings that can be automated by your IDE and by definition will not break anything.
Nowadays people seem to use "refactoring" to mean "changing code without adding new front-facing features." This is bad as it causes large, scary changes to fall into the realm of "refactoring." Refactoring, if you want to live by its original definition, should be a relatively mindless, safe series of small well understood steps.
I think this is a great post, it covers a topic succinctly and agree with its conclusion.
On the topic of actually refactoring code I think we should consider the code as a variable - that is to say, sometimes these variables just happen to equal each other in which case they are two separate things. Sometimes two variables aren't just equal, but they're the same. That's when to factor out the code. Otherwise the second these two variables are no longer equal you end up in trouble. The secret is divining when something is for all intents and purposes the same as something else in this specific situation.
Refactoring is probably a sign of problems, unless by refactoring one means ”giving abstract structure to yet unstructured code”, i.e. factoring for the first time.
That needs to happen after feature-completeness, but before a project goes into maintenance.
I like the breakdown and agree with your general line of reasoning.
I’m confuse though why you don’t just say refactor. This just reads like you redefined “refactor” to be adding layers and “defactor” to removing layers.
Textbook refactoring, changing a program internally without changing it external. It’s up to the refactorer to choose what to apply.
Applying a refactor is not only adding FactorBeanProxies. It can, and must be, used to remove parts as often as adding them.
If it no longer works then I don't consider that to be "refactoring" but "rewriting".
I think of refactoring as a series of SIMPLE transformations that clearly do not have any effect on the correctness (or incorrectness) of the code. That is, there is no possible change in behavior.
And think of the word "factoring" as in high school algebra. or rather "factoring out" something.
I have a dozen examples of this calculation. How about let's refactor it into a function, and replace all the instances with a function call?
Yes! this quote captures my reasoning of factoring before rather than after. The other problem with factoring after is that it's doing so without knowing the future new motivations. I would say that the factoring after is to suit making a working prototype first, then when a factor is identified aligning the design/source along those lines.
Note I say factor rather than refactor since in most cases the existing code wasn't factored in the first place. It's also a reminder that we should know what that factor is before making changes. In some cases there is a new reason that changes which to factor but is less common IMO.
I don't like that blog post on "semantic compression". He's rediscovered refactoring but doesn't think so:
> This is a very bottom-up programming methodology, a pseudo-variant of which has recently gained the monicker “refactoring”, even though that is a ridiculous term for a number of reasons that are not worth belaboring at the moment. I also think that the formal “refactoring” stuff missed the main point, but that’s also not worth belaboring. Point being, they are sort-of related, and hopefully you will understand the similarities and differences more over the course of this article series.
Um, what? Refactoring is called refactoring because that's what it is: You're pulling out a "factor" of the program and reifying it into a symbol which then replaces the factored code. "semantic compression" is a great name for it, but it's been the done thing in Forth, for example, for many decades.
It's just like factoring polynomials.
This is a textbook example of what I call "half-smart": He's smart enough to write this article, but not smart enough not to.
(Also that site disables reader mode. Boo! Why would you do that?)
Indeed. Refactoring means restructuring code in a way that doesn't change its external behavior. If we define bug as incorrect external behavior of code, then refactoring excludes bug fixes.
Refactoring doesn't necessarily even mean that the original code was structurally bad. When new features are added, code gets more complicated, requiring more abstraction. I like to abstract code via refactoring when we need it, not before. Then refactoring changes good code to good code. It's just that the new situation presents different demands to the code than the old situation.
reply