debuggable

 
Contact Us
 

What is refactoring?

Posted on 21/4/07 by Tim Koschützki

Today I feel like writing about one of the most important topics concerning php development: refactoring. Make sure you check the other articles in the Refactoring Category. They will contain examples of refactorings and the like.

A definition

Refactoring is the process of changing a software system in such a way that it does not alter its outer behavior, but changes its internal structure. The goal is to improve the internal structure and to clean the code - in order to minimize chances of introducing bugs later. Summing it up when you refactor you improve the design of code after it has been written.

- "Refactoring" by Martin Fowler

Improving design in later stages

It's the same with most modern software development teams. Before the coding comes the design, but as more people work on the system, deadlines need to be met and the general motivation to work on the project sinks, design becomes more and more hacking. The integrity of the system according to the pre-defined design gradually fades.

Refactoring to the rescue. With refactoring, the opposite of this practice, you can take a bad design and rework it into well-designed code. Each of the steps you undertake is very simple. It might be as simple as moving one method from one class to the other or renaming a class' attribute. Yet the culmulative effect of these small changes can improve your overall design dramatically. They will make your code easier to understand, reusable and - most of the time - a lot shorter, too!

When should you refactor?

Often! Never let the system's design overwhelm you. When you feel something is not right, put your refactoring hat on and redo it. It will make your teammates count on you. Just imagine if you would not refactor the code. As more and more features are added, the system becomes more and more complex and you would need more and more time to think yourself into it everyday. With refactoring that is not so. Refactoring ensures your code reads like a book.

About switching your hats: that's essential. Never refactor a portion of the system when you are adding features to another. This will lead you to the road to hell, introducing bugs and - worse - you will have no idea which code is causing them. Ensure that you have the code you want to refactor covered with Unit Tests so you do not break anything.

More on the subject later!

 

You can skip to the end and add a comment.

Leif  said on May 06, 2008:

The definition is almost copied from the Refactoring book. Reads a little odd if you know the book. Why not just quote it?

Tim Koschützki said on May 07, 2008:

Thanks for the heads up - the blockquote tags must have slipped through the cracks during the blog migration. :[ Fixed.

deltawing1  said on Jun 25, 2008:

"About switching your hats: that's essential. Never refactor a portion of the system when you are adding features to another. This will lead you to the road to hell, introducing bugs and - worse - you will have no idea which code is causing them."

Bloody good advice.

This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.