Fear Of Refactoring

Refactoring is defined as the process of restructuring existing computer code without changing its external behavior. For non-developers this sounds stupid and many managers don’t understand why it needs to be done as they are only focused on adding new features. The main goal of refactoring your code is to make it easier to maintain and and new features. It should be a common practice for code that is still heavily being worked on, and assuming old code already applies to your standards you can leave it. When you however all of a sudden need to change something at the old code you might be tempted to just hack it in. After all it doesn’t change that often anymore and while this might still be good for it is definitely a killer mentality if stuff will be added to it later again.

So you have come to the point where you either can no longer hack in the thing you need, or you just can’t stand to look at this pile of dirty code. So you decide to clean it up, most likely the code will not be very clean and thus hard to understand so the first thing you need to do is understand what is going on, after all just making changes to code is bound to break things.

After you understand the code you can start to restructure it and if you use a modern IDE you can get a lot of assistance with this ensuring you everything goes smooth and no links are broken. This not only minimizes the work you have to do but also the risk of breaking something. I used these features quite often and while they are good for the basic operations, it is when you want to do more complex refactoring that they fall short. Having to do this critical job by yourself without any guidance is very tricky as the chances of breaking something increases dramatically.

I have worked in a company where it was forbidden to refactor any code, moreover it was forbidden to touch more code than barely necessary to add the feature of bugfix you had to implement. While this rules was quite often broken it shows the fear that was present from breaking something. The reason is obvious, you don’t want to introduce a regression in your application as customers rely on it. But this should not have been a problem if you have enough unit tests. If your application has enough tests that guarantee everything will keep on working there should be no fear of refactoring as it can be easily found that something was broken.

It is not healthy to keep on working on code that never gets refactored. You will end up with a lot of unreadable code nobody understands and only has a vague idea of what it does. This becomes a cycle, as more dirty hacks are introduced the less people understand and can read the code, so the more fear of breaking something and thus more hacks are used. You should break this cycle at any cost, starting by writing unit tests that check the contract of the unit. It might be possible you already found bugs just by doing this, but since the goal of a refactoring is to keep functionality intact they may not be fixed. Once you have decent tests you can refactor as much as you want, running your tests again will tell you if you broke something or not.

There is a whole world full of refactoring you can try out now. Be sure to check this catalog by Martin Fowler.

Advertisements

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