When Should We Refactor?

2 11 2008

My friend asked me about when is actually a good time for refactoring, or even what are the ‘signs’ to do it. I’ll try to elaborate this thing.

Right time for refactoring is ASAP: refactor early, refactor often, as believed in broken windows theory.

Keep track of the things that need to be refactored. If you can’t refactor something immediately, make sure that it gets placed on the schedule. Make sure that people of the affected code know that it is scheduled to be refactored and how this might affect them. Remember that team has major role for this task.

According to Martin Fowler ‘s simple tips on how to refactor without doing more harm than good:

Don’t try to refactor and add functionality at the same time.

Based on experiences, there are number of things may cause code to qualify for refactoring:

  • Duplication. Remember the DRY or DIE principle, duplication is really bad.
  • Nonorthogonal design. You’ve discovered some code or design that could be made more orthogonal. In my experience, this step is the toughest one.
  • Outdated knowledge. Things change, you know something better for your code, you know there are new better solution for your code. This is the time for you to keep up the code.
  • Performance. We need to refactor codes when they have bad performance.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: