🇺🇸 Refactoring: Don’t underestimate it

I’d like to kick off this post by saying something that I recently learned: Don’t be afraid of refactoring.

The reason I’m writing this is because I recently read Martin Fowler’s book: Refactoring — Improving the design of existing code, which I totally recommend you to read it. This changed my way of seeing this topic.

I’ll leave down below a few points that were important to me when considering the change on the way I code. It is not easy to teach yourself this, specially if you are used to code in a different way, but worth a try.

What is refactoring and why doing so?

Refactoring is the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure.
- Martin Fowler (1999)

It is a constant attempt to write code less error-prone and an improvement of the design after it has been written.

When you think of building engineers, for instance, they know far in advance how buildings need to be constructed because there are rules and laws that guide them on previewing the best resources for a specific project.

The story is different with software engineering, because business are dynamic projects that tends to change based on several factors that aren’t ruled by laws.

Given your business is always growing and changing, when you don’t apply refactoring, then your code design tends to become a hacking tool to attend the business. This will slow down you and colleagues on finding bugs, predicting effort to a new feature and eventually stop attending the business needs right on the time it requires.

On the other hand, by always applying refactoring you can get the benefit of actually read the code and understand what is happening, so your bug fix is clear or your new feature has a clearer place to be.

Testing

Testing will be your first ally on this subject and will increase the quality of your software.

The reason I was always afraid of refactoring is that changing existing code that already works, might lead you to create new bugs on the code. But if you have a good test suite in the first place, you will always have them watching your back. Also you spend less time debugging your software.

Having that said, first of all make sure you have tests before touching your code base for a feature or bug fix.

Apply the refactoring

There are several ways of refactoring that won’t be covered in this article, but if you basically look for code smells and apply some refactoring techniques you will be in a good place and helping the next developer that will touch this code.

The basic rule here would be: Always leave the campsite better than you found it before.

Build and run your tests

Every step of the way, make sure you build and run your tests. This way you find earlier when you made a mistake — we are humans and this is normal.

Will you find tools that really help doing this job. A good example is Visual Studio with the Live Unit Testing functionality.

Wrapping up

If you apply the constant process of write tests, refactor, build and run, as a developer you will see an improvement on your performance, the way you code will change and you will start to think on the next developer that will eventually code on top of yours.

You will start to have questions like: If someone else look at this code, will he/she understand it? Is this name according to my domain language? Is this variable name meaningful? Is it possible to correlate the acceptance criteria by reading this code?

With this mindset, I believe this famous phrase was formed:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
- Martin Fowler (1999)

In essence, be reasonable to the next that you will code better.

What are your experiences with it ? Do you have anything to share ? Leave a comment or find me on Twitter as @_arleypadua.

This article is also available in Portuguese.