Refactoring in 5 Minutes – A Non-Technical Reading

“We need to refactor this code,” someone says, and suddenly an atmosphere of terror invades the meeting room. “Refactor” such a weird word should be related to something that is so extremely complex that only the bravest developers dare to mention it.


What is that?

Refactoring is defined as “The process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

Sounds good, right? Well… no, why would someone need to change the internal structure of a code that has already been written? The answer is simple: the code is always changing. Each time that we add a new feature or fix a bug, we are changing the internal structure of the base code and as a result, we end up with a structure that does not represent anymore the original design.

Another problem is that code tends to get more complex with every line of code we add, so it gets harder to understand. Also, the typical trade-off between delivering fast and make a robust design (that would take longer to deliver) increases the technical debt which is supposed to be tackled later in a  (guess what?) refactoring task.

With refactoring, you can take code that went through these examples and rework it into a well-designed code.


Ok, it seems to be something normal in the software life cycle, what’s the big deal then?

There is some kind of connection between the introduction in this article and the task of refactoring code. The following scenario is described by M. Fowler in his refactoring book:

You start digging in the code. Soon you discover new opportunities for change, and you dig deeper. The more you dig, the more stuff you turn up…and the more changes you make. Eventually, you dig yourself into a hole you can’t get out of.

Also, the risk of introducing bugs when refactoring is very high, even more, if the code that needs to be refactored does not have good coverage.


So, is refactoring an extremely complex task?

No, it’s not if you think about refactors as a specific step that every developer should go through when fixing a bug or adding a new feature. This way refactoring will be something of everyone’s daily basis rather than an extreme adventure.

In M. Fowler  words:

“Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design… With refactoring, you find the balance of work changes. You find that design, rather than occurring all upfront, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.”



Refactoring is not an extremely hard type of development task, it’s a good practice that every developer should embrace: it contributes a lot with the health of your code, and makes testing, reading and adding new stuff way easier if it’s done periodically.


Works Cited

Fowler, Martin Clay, and Kent Beck. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2019.