Practical refactoring [closed]

Question

I've read about refactoring and probably did it before I even knew about it, however I don't really know much about it is actually done and what it practically means.

• What, from your view, is refactoring?
• How and when do you do it?

Answer 1

What, from your view, is refactoring?

As a purely academic definition, refactoring is a material alteration in existing code that does not (in theory) affect behavior or output.

In terms of practical implications, it can be a variety of things. As a small sample:

• Moving repeated code blocks into dedicated functions
• Giving variables clearer or more specific names
• Altering class relationships to better reflect real-world relationships (or class redesign in general)
• Decoupling previously interdependent code

If it sounds like a lot of those examples should have been done up-front, that's intentional; a lot of refactoring is simply adapting code that you wrote into how you should have written it to begin with (though, to be fair, a lot of refactoring also doesn't fit this description).

How and when do you do it?

The "when" is both short and largely unhelpful: when you can and when you have to.

When you can, it's important to make sure that code you've written isn't going to cripple (or hobble) you in the future. If you took shortcuts up-front to ship a product on time, then you may get a chance during future periods to dedicate a little time to refactoring. The idea of having "down time", though, is obviously just a myth in the business world ;)

The times when refactoring is required is usually a judgment call that says "it will take less time for the team to refactor this code to what it needs to be for this change (or to fix this bug) than it would to write the new code in such a way that it fits with what's there". This is a situation that should be avoided like the plague; refactoring is more dangerous (in general) than new code, as you're changing what's already (hopefully) been tested. Doing this under what is, by definition, a "time crunch" is even more dangerous.

Like most maintenance coding, refactoring has little to no short-term benefits (after all, you aren't changing output). The benefits come, like proper up-front design, in the form of decreased future maintenance burdens and faster (and, hopefully, more reliable) changes.

On the upside, refactoring can be enjoyable (though it can also be maddening at times)