Refactoring Is a Mental Thing / Psychology of Refactoring
Tags: refactoring, cleancode, psychology, learning
Published: 2021-08-21 15:15:07

Most of the times refactoring is portrayed as a skill, which is true, but the psychological aspects of a person who does engage in refactoring activities are completely ignored.

The common definition of refactoring is as follows - *"Refactoring consists of improving the internal structure of an existing program’s source code, while preserving its external behavior."* This definition is truthfull, **but most of the times it is not**.

Before we can fully dismantle the popular definition of refactoring, we must first dive into psychological aspects of this practice and why would anyone refactor at all?

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i2c217key6f9youfx36w.jpg)

## Exercising

For the sake of the argument lets say, that less than 15% of the people exercise once a week. When commiting to an exercise session, you simply commit to a **short term loss** - time, energy, hard work, mental effort and after the workout session you still have a muscle soreness.

You must commit a lot of resources to get no perceivable benefit in a first few days, and after those few days, what benefit will be there? You have no *score* that goes up, you have no sixpack after one, two or 10 training sessions, so there is nothing you get in return that can be shown to other people.

There is a difference between **short and long term** mentality. When we exercise we **expect to benefit from it in a long term**. We expect to be healthier, faster and more flexible, but we also commit to the fact that our gains would not be obvious to us.

## Why is refactoring any different?

Using the example of exercising, we can draw a lot of parallels to refactoring:

 * there are **no short term benefits** of refactoring
 * the **gains** are not obvious, your score doenst go up
 * people refactor, because of a **long term benefit**

We can safely assume that less than 15% of people actually refactor their own code. There is no perceivable benefit. Your client would't tell a difference and you just completed your work faster, without wasting time to refactor, so why bother?

Thats where we come to one critical point - refactoring should not be done *"while preserving its external behavior"*

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6ymd0tktvde6p2tr0i09.jpg)

While refactoring, you should oftentimes try to *"mess"* with your application.

 * You should strive to make your code more readable
 * You should strive to make your code more flexible to changes in data or changes in dependencies / submodules
 * You should strive to convert existing code, into your own submodule or dependecy, so your code can have more than one purpose

And you know what? When you do that, you oftentimes find bugs in your code or negate the existance of future bugs and issues, and you also learn more from your mistakes. So *"preserving its external behavior"* is kind of wrong. For an uninformed observer it might be a *"preservation"*, but oftentimes the result is just faster code that is less prone to errors.

## The Dilemma

You cannot say - "Ladies and gentlemen, today we avoided 2 bugs, we can more easily migrate our application to the new platform, and we would need to spend less time developing new features, because I exactly 2 months ago, refactored this part of our application for no benefit at all!"

You cannot point to the issues, which did not came to the existance.

So why bother?