RSS
Deepak Kumar Sharma

Refactoring: Refactor your thoughts before code

Tue, Jul 6, 2010

Deepak Kumar Sharma

Ahem…. Ahem!

Well, when I thought of writing about this topic, was not sure where to start, but it has to be from somewhere. I love to introduce this word from the day it entered in my life. Probably you are wondering how come a word entered in someone’s life.

Don’t give pain to your brain; Let me tell you it is the word “Refactoring”

That was initial days of my new project; one fine day we got code from client, which he had developed from some other vendor. The moment I saw the code, my first reaction was; how can a person write code bitter to this extent? Literally, it was written very badly, even a good college student can write better piece. This was the point when I thought, is there something I can do with this code to improve it? And the answer was “Refactoring”.

Refactoring!!! This word has most influence on my mind in past few months. I had gone through many articles, books and all whatever I have access to. I found this quite interesting and very useful for software developers. Especially for those, working in large teams, long term project or uses agile development where the project design changes more frequently.

The very first thing to understand is that “Refactoring” is not solution of all software ills. Refactoring is a disciplined technique for restructuring an existing code, altering its internal structure without any change in its external behavior. It consists of a series of small transformations, which essentially preserves program’s behavior. Each transformation does very little, but a sequence of transformations produces a significant change.

One general perception I observed in most of the people, who think that refactoring always splits the code and creates more number of classes. This is not always true. There are some transformations which are opposite to this. They remove classes and minimize hierarchies.

I deliberately don’t want to introduce you with refactoring techniques here. I believe you can easily find them out on so many places via web search. Here, my objective is to talk about the concept behinds the refactoring idea and its relevance to developer’s life. One thing I really want to stretch upon is “Performance with respect to Refactoring”.

I had many discussions, where people try to compare the refactoring and performance; especially when some refactoring transformations make visibly negative impact on the performance. To make the program easier to understand, we generally make changes that result into program to run more slowly. I agree that software should not be too slow; otherwise they are not going to be accepted by end user. But here the point is; do not mix the performance with refactoring. You should not try to achieve both in one go. Even In classical software development approach the performance optimization is always comes at later stage. So first write tunable software and then try to tune it for sufficient speed during optimization.

With the study of thousands of projects, it is found that there are only 5-10% software which really having performance issues and out of this small bucket almost 95% project falls into category where the performance is hampering due to only 10% of code. These are known as hot-spots. So rather than optimizing the whole code in the project, during entire life cycle, why not we optimize only that 10% of code, moreover only if there are priority performance issues.

There are two types of development approaches -

First, most of developer follows. They try to write optimize code all the time they do coding. They are not much bother about refactoring and writing code that is easier to understand /maintain in future. Their main attention goes with efficiency and optimization of code. Here what happens is; as the project grew, it gradually becomes difficult to add more features and change the existing ones. The code is not that tunable in nature.

Second, go with refactoring, all the time you write code. In this case even if you project grew, the code will remain more maintainable, easier to understand and more extendable. This helps to do faster development. Even if some performance issues arise, you will be in well situation to figure those hot-spots and apply performance optimization techniques to get desired increase in the performance.

I think it’s time to signoff. If I still continue to write, it would be difficult for readers to digest in one go.

Hope you had a good time in reading.

Good bye

Popularity: 82% [?]

5 Comments For This Post

  1. deepika pathak Says:

    nice one..:)

  2. suby cherian Says:

    Hai Deepak

    I am totally agree with u
    We have come those difficulties lots of time
    Its a nice method

    Looking forward to more articles

    Helloplot.com

  3. MCSA Says:

    Don’t give pain to your brain; Let me tell you it is the word “Refactoring”

    That was initial days of my new project; one fine day we got code from client, which he had developed from some other vendor. The moment I saw the code, my first reaction was; how can a person write code bitter to this extent? Literally, it was written very badly, even a good college student can write better piece. This was the point when I thought, is there something I can do with this code to improve it? And thanks

    AKHILESH SINGH

  4. indian real properties Says:

    i totally agree all of above comments.

  5. Hemant Gupta Says:

    Hi Deepak,

    Really nice!!

Leave a Reply