Introduction to refactoring

Let’s start with the definition. More specifically, the one that can be found in this Wikipedia article.

The first definition (not so good)

“Refactoring is the process of restructuring existing computer code, changing the factoring without changing its external behavior.”

— Wikipedia

The definition is correct from the point of view of a trainer, someone who already has this knowledge that you want to convey. However, words convey nothing beyond what they merely express. That is, from it we can extract:

• Technique (The action)
• Software engineering (The scope)
• Restructure a code (The what)
• Without changing your behavior (The how)

If we stop to think for a moment and are able to put ourselves in the point of view of a learner, we will be able to detect in it the absence of the two truly important parts, the most essential to transmit the concept. These are the why and the for.

The second definition (much better)

Let us now see, on the contrary, how refactoring is described in the following definition, extracted from the book Refactoring Workbook, written by William C. Wake.

“Refactoring is the art of improving the design of existing code in a safe way. It provides us with ways to organize problematic code and gives us guidelines to improve it.”

— William C. Wake

From it we continue to extract:

• The action, in a perhaps more accurate way, focused on craftsmanship in “the art of”.
• The scope, in “the design of a code”.
• The what, in “organizing a code”.
• The how, in “in a safe way”.

But we also have:

• The why, in “problematic code”.
• The for, in “improving the design”.

Conclusion

The purpose of refactoring is to improve the design of the existing code.