Developer’s Sins: Fear of refactoring

Legacy

Code is legacy code as soon as it’s written

I know you have seen this ugly, scary code, during one of the bugfixing sessions, or when adding some features to the existing codebase. Everyone did.

I know sometimes it feels like the class, or method has been written ages ago and what is worse: apparently it is working fine, for now.

We don’t like those names for variables, we see that repetitions in code, we could even swear, that this code could be much shorter and cleaner.

But who would touch such an old code, that works fine, only to make ourselves more happy when looking at it? It may generate bugs. Last thing we would like to do now, is to need to dig into the specifics of this code to fix a bug, it’s a production code.

For now

So what happens, if the code is not improved over time, and one day it stops working? Or, when it should work in a slightly different way soon? Will it be easier to work with it if you leave the code untouched?

If developer fears to refactor, it’s very likely that in case of changes or fixes, the modifications will be applied locally, by adding only the needed parts. Hopefully it won’t break anything, and will work fine. At least for now

It’s clearly understandable why people tend to approach such topics like that. They fear the consequences. It’s also simply easier to do it this way. No need to write unit tests, no need to spend too much time to analyze the code, no need to explain to the boss, why such a small change took us two days.

Technical debt

There are many articles that are describing how short should methods be, speaking about optimal number of arguments for a method, or how the variables should be named. But if you continue to work with the code the way I mentioned before, those recommendations may be bit far from the reality.

So, methods that count thousands of lines sound unreal? What about tens of thousands for the class? Have you ever seen a method with over 2k lines of code, where each 100 – 200 lines there is a 10-lines long ‘if’ statement that defines the condition for the next 200 lines of code? Can you imagine how does one debug complex scenarios in such code? That’s what you call Technical debt. Dozens of small changes that build up one big holy piece of crappy code that nobody wants to touch.

If you need to fix a bug in such code quickly and you see such code for the first time, then believe me, my friend… You are fucked.

Safe refactoring

All that being said, we don’t want to think IF we should refactor, but WHEN? Developers that are afraid of touching code because of regression risk, would also ask HOW?

Refactorization: a rewriting of code to improve its readability or structure without affecting its meaning or behaviour, thus making it easier to maintain.

Readability, easier to maintain, sounds good, huh?

I believe, that there are at least couple of things you can do, to reduce the technical debt and move the topic forward without a big risk of taking the application down.

The quoted definitions and code examples are from catalog of refactorings, from Martin Fowler.

Extract Method

You have a code fragment that can be grouped together.

Turn the fragment into a method whose name explains the purpose of the method.

What kind of risk do you see with method extraction?

If the code is closed inside of a method, there’s no big risk when extracting it to a separate method, nobody else is using it anyway. It will shorten your method, and possibly allow you to reuse some small chunks of code.

Extract private first, to not make other classes dependent if people will find your method. Then use other refactors, to move forward (Extract Class, Extract Interface, …)

Extract Variable

You have a complicated expression.

Put the result of the expression, or parts of the expression, in a temporary variable with a name that explains the purpose.

Boolean conditions from if-statements are probably most often the first places to look for. Fits also well for foreach collections and many other cases.

if ( (platform.toUpperCase().indexOf("MAC") > -1) &&
     (browser.toUpperCase().indexOf("IE") > -1) &&
      wasInitialized() && resize > 0 )
{
  // do something
}

You can change it to:

final boolean isMacOs     = platform.toUpperCase().indexOf("MAC") > -1;
final boolean isIEBrowser = browser.toUpperCase().indexOf("IE")  > -1;
final boolean wasResized  = resize > 0;

if (isMacOs && isIEBrowser && wasInitialized() && wasResized)
{
  // do something
}

You can reuse the variables now in other places of your code, which is additional benefit, except the easiness of reading the code.

Rename Method

I hope this one doesn’t need any explanation. There is this method, which name is not saying what is it doing. Quite often it doesn’t say anything to anybody, not even lying.

It’s important to know the impact of changing public methods, as somebody might be using it already, but at least for the private ones, it should be done ASAP. There are two categories of private methods that are likely existing in the code that I describe below. Hopefully private, given their context.

  1. Geek joke names. It might sound silly, but wrong naming, is probably the worst thing in the world. It is not funny to name methods like that, it’s a slap in the face of other developers. Don’t do this. Rename whenever possible.
  2. Scary names: the name suggests something important is done inside of the method, but nobody should touch it, due to the importance and complexity of the method. Don’t do this. Rename whenever possible.

Rename Variables

This one is very simple. If you have variables names like: x, y, a, b, var1, var2 etc. you have to rename them. See what are they responsible for, name them appropriately, make the code readable. Every second invested in this process will pay back quickly.

Clean warnings

Yes, I mean it. All the ‘variable is not used’ and other things that people often keep in the code, because ‘nobody has time for it. Find the time. Clean this mess. Get rid of those annoying stuff you waste time to read.

Even if you don’t focus on it, believe me, you waste time reading it when it scrolls after build.

Old Commented Code

You’ve seen it for sure.

//Before it was done like that, I keep the old code for the future.
//... some code

In visual studio, I’ve also seen it wrapped in #regions.

Nobody cares about old code. This is why we have repositories and version control. Remove those comments, keep the code clean.

Go further

I can assure you, once you start working with code, you will see it doesn’t hurt. The more you get into it, the more you like it.

You could check this awesome refactoring catalog from Martin Fowler, the more you read, the more you find it obvious.

Keep writing unit tests, keep simplifying the structure of the code. It will make you understand the code better and what is more, FEAR LESS.

One thought on “Developer’s Sins: Fear of refactoring

  1. Pingback: dotnetomaniak.pl

Leave a Reply

Your email address will not be published. Required fields are marked *