What is code refactoring? And what it isn't? Take a daily 10-minute workout routine that you'd stick to for a year and compare it to one... month of intensive, “hardcore” workout marathon worthy of a true... gladiator. 

During which you'd take time off from your job and your personal life in order to get your code back in tip-top shape.

Can you see what I'm trying to outline here?

If for you refactoring code means a long haul of massive changes (e.g. completely revamping the GUI, migrating to a different database etc.), a time where you stop delivering and you invest all your time and energy in this “project”, then you've got it all wrong.

For this is NOT code refactoring.

It's an inefficient, time and energy-sucking, desperate “marathon” for structuring and deeply sanitizing your code. After a long period of writing sloppy, unruly code only and not paying too much attention to following the best practices and coding standards.

But let's delve into more details! Let's set the official definitions against simple real-life analogies, against some of the most common misconceptions about code refactoring.

 

1. What Is Code Refactoring? 2 Official Definitions

Let's start with the “all mighty” source of information, Wikipedia:

“Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior.”

Next, let's ponder on Martin Fowler's own rigorous definition of this notion:

“Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However, the cumulative effect of each of these transformations is quite significant.”

What can we conclude from these definitions is that:

 

1. code refactoring is a technique (let's choose this term over “process”) of restructuring/overall improving your code base 
2. a series of continuous, small code improvements/rather than a long haul of massive changes
3. with no impact, whatsoever, on your software system's functionality (aka “external behavior”)
    

In plain language: code refactoring is the sum of all those “healthy” little habits that you intuitively stick to, as a developer, for reorganizing your code base; for keeping your code cleanly structured, without implementing any new functionality!

 

2. A One-Time Massive Change vs (Continuous) Small Code Improvements

Or:

continuous little efforts vs one massive cleanup marathon

Now what I'm trying to (more or less subtly) point out here is that refactoring your code has nothing to do with:

 

1. adopting a brand new database
2. giving your GUI a complete overhaul
    

Call these 2 time-consuming activities any way you want — “legacy rescue” or “overhaul” — but not “code refactoring”.

For refactoring your codebase doesn't involve massive changes. It's not some sort of clean up endurance test.

But rather a ”discipline” that you stick to, based on small improvements applied to your code.

“Improvements” which, taken separately, might seem of too little significance. Yet on a long run, and viewed as a sequence of continuous efforts, these small constant changes are far more sustainable than a tedious, time-consuming code clean up marathon!

 

3. Automated Tests: Avoid Unintentionally Changing Your System's Behavior

So we've cleared up the most “popular” misconception. One that might have given you the wrong answer to your “What is code refactoring?" question.

Code refactoring is NOT massive changes that would inevitably impact your system's functionality (or “external behavior”, you prefer).

But what if you risk altering your software's functionality unintentionally, as you apply one change or another?

And here we reach another one of the common misconceptions about code refactoring:

That it's about applying changes to your codebase without any robust suite of automated tests at hand!

Automated testing is the surest way and most practical means of:

 

1. detecting any behavior changes that you might unintentionally make to your system 
2. ensuring that your improvements don't influence the overall functionality of your software system, as well
    

4. Summing Up: What Code Refactoring (Truly) Is...

… a series of bite-sized changes, backed by a suite of automated tests. In short:

If you're coding, then you're implicitly and simultaneously refactoring code anyway.

It's not a project, one that would ask you to “freeze” everything till you've completed it, but rather a constant, lightweight improvement of your codebase. 

Now speaking of these little habits or small changes that you're doing anyway while you're writing code, let me highlight some of the most common ones:

 

• removing outdated, no longer relevant code
• renaming variables in a single method
• segmenting a large method into smaller parts
• enhancing a class' readability by adding whitespace
• removing code that has been commented out
   

See? These are all examples of improvements that you're already making to your code, on a regular basis.

Low-effort, simple improvements that don't impact your software system's functionality. 

Take the “clean as you go” method of keeping your home clean and neat all the time vs the “clean up marathon” method. Where you would take a weekend off (at least) to deep clean it. This after an unacceptably long period of completely ignoring your daily clean up tasks.

So “What is code refactoring?”

When/if done right, it is a code improving technique that you're already applying.

Writing code and doing code refactoring are so interwoven that at some point you probably stopped perceiving them as 2 different activities.

 

5. What to Expect from this “Healthy” Approach to Code Refactoring

In other words:

What would you gain from starting to view code refactoring as a development technique instead of a project?

Let me try and answer your question with a specific example:

Imagine that you're this developer who's been deviating from a good coding standard and who has been systematically writing unrully, bad code due to various reasons. Tight deadlines, technical debt... laziness... Then, after all these years, you engage in THE “project” of giving your database a deep cleaning.

Or what you used to call: “code refactoring.”

Now starting to perceive refactoring as a continuous and constant series of daily little improvements made to your code you'd be actually:

 

1. avoiding the risk of changing anything about your software's external behavior
2. skipping that part where you'd put everything on hold for a couple of months to get your code back in shape
    

So, “What is code refactoring?” for you? How would you define it?

---