Refactoring for the Uninitiated

Refactoring for the Uninitiated

Refactoring is very important in software development. This is true for new and existing software.

Code refactoring is the process of restructuring existing computer code … without changing its external behavior.

Wikipedia

Reorganizing, cleaning, and changing code to make it more maintainable is not something new. However, in the last few years the practice has been formalized. This process probably started with the seminal book by Martin Fowler, Refactoring: Improving the Design of Existing Code.

A Simple Example

Here is the simplest example I can think of, an application for administering customers. We have a class, Customer, that simply lets us save data about the customer, but first it must check for required information, like first and last name, and birthdate. The code is self-explanatory.

Client before refactoring

Refactoring

This is a pretty simple class, right? However, it could be improved when it comes to checking for required data. You’ll notice that the Save method first checks that these data are not null (and empty in the case of the first and last name strings). The code is not “wrong,” but it could be better.

Client after refactoring

The only thing we’ve done is move the code in charge of validating the required data to its own method. Then we modified Save to use this new method. This is an example of a common refactoring pattern called Extract Method.

The new code has the following advantages,

  • The Save method is easier to understand. The new method, ValidateRequiredData, makes the code more self-explanatory because it tells exactly what’s happening. In general it’s better to have small, single purpose methods, commonly called highly cohesive methods. They make the code easier to understand and, therefore, more maintainable.
  • Also, this type of refactoring makes the code more reusable. In a real world application other classes may need to validate required data, too. If that’s so, we could easily make the validation method public so it can be reused instead of duplicating the code elsewhere. This helps us to follow the Don’t Repeat Yourself principle as much as possible.
  • If later on we have to change the validation (e.g., check for specific data or other variables), then we can simply change ValidateRequiredData instead of having to hunt down all the places where this validation may be done.

More Examples?

Providing longer and more complex examples would make this post too long. I have created a more realistic, and, I hope, interesting example that you can find in GitHub.

In the meantime, here’s some very wise advice,

refactor your code jlpicard 

Conclusion

Obviously, this is only a simple taste of what it’s like to refactor code every day while developing production code. It’s much more interesting when we run into more complex code that can be more difficult to refactor.

In the most interesting cases we have to bring into play everything we know about OO programming, design patterns, and good practices and principle like SOLID, DRY and KISS.

Refactoring is in my opinion one of the most important tools that software developers need in their arsenal. Regardless of what technology you prefer, good refactoring is a skill that will help you make code more maintainable and easier to understand. Countless other developers will thank you for it.

Software’s primary technical imperative is managing complexity.

— Steve McConnell, Code Complete

Take McConnell’s words to heart and refactor your code whenever needed.

You can find the original version, in Spanish, here.

Focus Mode

Contact Request

Close

We will call you right away. All information is kept private