developer.* Blogs - Refactor-itis - Comments

Refactoring Outside of a Vacuum

Daniel Read — Mon, 15 May 2006 09:34:31 -0700

Hi, John, thanks for your comments. I agree with you that refactoring should not be resisted simply because of fear of change. I think the interesting part of the "should I refactor this?" question is the larger picture--as in the example above, if we refactor a public interface without considering the "contract" implicit in that interface, then we can break other people's code in the process. I would say also there is a general risk consideration: how complicated and intertwined is the code you are looking to refactor, and do you have the time and resources to ensure that the code will still behave the same after you're done? In a production maintenance situation or under schedule pressure, if the risks outweigh the rewards then the prudent thing might be to simply add some good comments to the code rather than refactor it. That's not resistence to change, just professional pragmatism.

Anyway, I don't mean to come off as lecturing you. I agree with your point: if better quality will result, go for it. But like those physics problems where the formulas only work if you assume the absence of gravitational pull or friction, sometimes reality gets in the way.

Dan

Refactoring for quality

john3223 — Mon, 15 May 2006 00:37:13 -0700

I do not see anything wrong with refactoring,if it is done for a better quality. After all, we are living in a progressive era. Things are progressing and changing everyday at fast pace. It would be inappropriate to resist the changes.

Refactoring with sense

Mario Van Damme — Tue, 25 Apr 2006 08:01:39 -0700

I totally agree with your statement that refactoring for fun is not acceptable in a professional environment. However, I've seen people working this way systematically : constantly changing interfaces under the cloak of 'refactoring' instead of taking one step back and checking why it needs constant revising without requirement changes. The root cause (in this example) was that the developer simply didn't think things through.

Damith gave a good response on the refactoring of interfaces : People are not always fully aware that they are not the only consumer of a certain interface.

For example, why is Microsoft's Visual Studio API breaking some of its interfaces every time a new version comes out ? The reason is simple: there's not enough emphasis on refactoring with sense.

Mario.

Refactoring and reuse

Damith C. Rajapakse — Sun, 23 Apr 2006 18:27:45 -0700

I agree with the guest's view that an interface may be refactored, as long as it does not alter the external system behavior. Of course what is considered 'system' and 'external' may differ if there is fine grain reuse across systems. For example if the said interface is reused for another system, then altering it affects a certain 'external' behaviour of the system. my 2 cents...

About the refactoring of an

Guest — Fri, 21 Apr 2006 06:24:57 -0700

About the refactoring of an interface: this is totally acceptable (and according to the definition of Fowler) if the behaviour of the system as a whole does not change.
It all depends on the point of view you have: you can refactor a single component (which means the interface will not change), or you can refactor e.g. the interaction between components (which means the interfaces may change, but the system as a whole will not).

On a more general note: refactoring is a natural part of the coding process. However it should be done early on, to come to a clean implementation as soon as possible.
If the code is left in a messy state, the refactoring will be required much later on (when the bugs start coming in), and at this point it will become much more expensive (and it will introduce more risks).
So: write good code in the first place, and the need for refactoring will be diminished.

Of course: refactoring just for the fun of it is never acceptable (at least not in a professional environment).

Refactor-itis

Mario Van Damme — Fri, 21 Apr 2006 00:23:29 -0700

I have an urgent need to talk about a disease which is a threat to the health of the software we create: "refactor-itis".