Skip to Content

So what’s refactoring?

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

This process is extremely useful for both the actual coder and for the person who maintains the code. The time to find a bug reduces drastically due to this process and also the ease of adding a new functionality increases.

The following insight gives us a better idea:
Refactoring is a kind of reorganization. Technically, it comes from mathematics when you factor an expression into an equivalence–the factors are cleaner ways of expressing the same statement. Refactoring implies equivalence; the beginning and end products must be functionally identical. You can view refactoring as a special case of reworking.

The key insight is that it’s easier to rearrange the code correctly if you don’t simultaneously try to change its functionality. The secondary insight is that it’s easier to change functionality when you have clean (refactored) code.

There is no need to go into the topic in this blog as there are tons of resources on the net but let me try to give some random statements on refactoring.

Refactoring is about making the code neat, simple and easy to manage. Some examples are: we combine two methods with similar behavior into one method,we break a long method into two shorter and simpler methods,we split a class having some twenty methods into three smaller classes,we inherit classes instead of rewriting certain behaviours,we add meaningful names to your variables and methods, and a lot more.

Most of us will be following these practices in our development process but refactoring is a formal term which captures the common sense practices of lot of developers and puts it under one umbrella. A single refactoring process might not add great value but all the refactoring practices applied together in a system improves the system drastically. We need to remember that  refactoring does not include any extension of existing functionality. Also refactoring and unit testing go hand in hand (though not necessarily) because every small change you do to your code might affect the system and if you have your unit tests running after refactoring then you are safe !
Another wiki talking about XP and refactoring:

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Sivakumar K S
    Knowingly or unknowingly all developers refactor. Whenever you edit your code to make it more rational, modular, reusable or just easier to read, you are essentially refactoring your code.

    Everybody knows they should refactor more , but manual refactoring eats up time and risks breaking code that works. Also, when a code block is used more than once, then we refactor it into a method. This is a common step we follow. But how many times do we do it when we write the code block for the first time? Owing to project deadlines and risk of breaking the code, we normally get onto the mode of skipping it.

    Imagine various refactoring methodologies provided inside the editor/IDE. It would be ideal for any developer to have those various nice automated refactorings available in the IDE that can kill the time and the risks associated.
    Microsoft in its Visual Studio.Net C# editor has various refactorings and our own Netweaver Eclipse IDE has all those refactorings available for the developer to use.
    Did someone say that its high time we use ’em up???


Leave a Reply