Code Refactoring

By Hélio Costa

You don’t need to follow the “testing world” to know what refactoring means. This word, which is used daily in technology departments, presents itself in two distinct moments throughout development:

The Miracle of Code Refactoring

• Refactoring: the third step of Test-Driven Development (Red, Green, Refactor);
• Refactoring existing production code

For now, I’m only going to address the second item.

The need for refactoring arises when one or more programmers have pinpointed a certain snippet of code and determine it isn’t constructed in an acceptable way.

Thus, a wise person should remember what refactoring means: keeping the behavior of the part that’s to be substituted.

Although obvious, this premise is the one most often violated when refactoring something, because along with refactoring something, the programmer tweaks a couple of things to enjoy some more PR.

We don’t need to reach to prove this doesn’t work well, do we? When refactoring you can crash things. And, to avoid that this crash doesn’t go into production, you need quick responses to whatever changes were made in the code, however small they are. (Hello, Test-First)

Secondly: with all your power, avoid creating refactoring tasks in the project. Refactoring should come with a purpose. Predicting the future is not a purpose. There’s no need to refactor something that has been long-established in production just for the pleasure of refactoring a piece of code. Since you should’ve already done it in the third step of TDD:(Red, Green, Refactor) If you want to study, do this at home.

The Demigod of Refactoring

Remember how I said you had probably heard the word refactoring in other environments? Whenever looking at code it’s normal for us to judge it and misunderstand what it does and why it does it. Our lack of understanding makes us say: ah, this needs to be refactored. But does it really?

This type of attitude can defeat the benefits of refactoring and even worse: crash something in production unnecessarily, simply because your inexperience as part of that team/project means you didn’t understand the code — which is perfectly normal whenever you’re new to something. This can destroy an entire sampling process, and totally undermines any case in favor of planned refactoring.

It’s important that you proceed with caution and wait until you’re more certain of things.

Refactoring Isn’t Always the Best Way Out

Another point, in favor of avoiding going around blindly refactoring, is having the analytical control of analyzing the scenario in question and verifying if code refactoring would even solve the problem. I’ve seen cases where the code in itself wasn’t the issue. The true problem was poor design, and in these cases, refactoring does nothing to help. Decisions would have to go further than that to solve anything.

It’s preferable to keep spaghetti code around for a while than to lose perhaps the only chance of showing the benefits of refactoring.

In podcast #157 of Ruby Rogues, Rebecca Wirfs-Brock affirms another important point:

You’re sort of arguing that refactoring is not necessarily always the best way to clean up a design. Sometimes, you might want to start over.

Sometimes it’s really better to just perform a mental git reset or git stash, as Avdi Grimm said when joking around, and to start another solution from scratch. A big ally in this process is Unit Tests with Test-First, since they give you a quick response concerning the progress or stagnation of your reasoning.

Summary

1. Quick responses to refactoring. Unit tests are the only way to achieve this in a fast and isolated way;
2. Refactor. Once ready, go back to implementing what you were going to do in the beginning. Don’t do both together even if Goku himself descends from the clouds to ask you to;
3. Don’t refactor upon entering a project: it’s a trap!;
4. Sometimes a mental git reset is better, move on to another solution;
5. Being supported by unit testing and test-first will give you the confidence to decide to refactor;
6. Make an effort to make sure refactoring doesn’t become a task of your project. It should be accompanied by a task of implementation. Refactoring needs a purpose;
7. Last but not least, Red, Green, Refactor (TDD) != refactor production code.

Our goal in Product Technology is to create the best solution to our customers’ needs by offering the most complete and innovative portfolio of financial products from financing to investing. We’re here to build a fully automated and intelligent digital platform and we’re looking for people who’ll join us on this link.