The Hitchhiker's Guide to Refactoring: Why, Where, When and How

 Arthur Dent was a Visual Basic spaghetti coder. Now, I have nothing against Visual Basic programmers,  don't get me wrong. There are some people that find what they like and stick with it. Arthur Dent was that guy and he did it for the wrong reasons. no matter what new adventure Ford Prefect and Zaphod Beeblebrox dragged him on there he was and he was stuck. Whether he was stowing away on a Vongon spaceship or colliding around time and space on the Heart of Gold Arthur Dent was just kind of going with the flow and allowing the mess. It sucked, but he wasn't going to stop it he was just going to complain. Trillian, to me, was a refreshing character that exploded off the page, that girl kicks. I've always had a special part in my heart for the girl that can storm into a chaotic room of disruptive scheming boys, quickly find the logical solution and start barking orders (whether they listened or not, in this case).

 

A programmer that knows how to refactor well is a Trillian. A true navigator, laying a sure, quick, path to the goal of the team. No mess is too intimidating and no solution is too distended. Lately I have learned that I have a real penchant for a good refactor. Especially now that I have my very own project, my bad boy is sleek, it's quick, and it's trim. It's a machine. How do you get to the point where you're comfortable knowing when to make the refactoring choice? I'm going to share with you what I have done in the last months, hopeully you can glean some wisdom.

Why Should I Refactor? 

        If we developed like we thought and no other way I think a lot of us would end up with a bit of a mess, and that's often what happens when putting together applications. Refactoring is a way to remove the bloat. To take out the extra junk that takes up space. It's also a way to improve functionality, to make improvements and additions easier. Lastly, it makes your application much more readable, and you know that with my passion for self documenting code that's one of the reason's I'm a big fan. 

Where Should I Refactor? 

    You should be very careful with this question because it's what stands between you and either a big mess,  a time sucking blackhole, or something absolutely beautiful.  I like to think of a refactored application as a skeleton, where the objects, the factories, and the utilities as the muscles (we can call the .css the skin if we want to get carried away). The more you refactor (the right way) the more power you give your application, more muscle. You give your application a chance to run itself, while you can work on features and shiny bells and whistles. To do this well have to ask yourself a series of questions as you code, you will get more and more sensitive to the process as it goes on. One is “Have I done this before?” another is “If I hadn't looked at this method (function... whatever you use) before would I immediately be able to tell you what it does based on clarity and variable naming?” also “Is there a better way to do this technically?” The answers will lead you to many potential sections to refactor, we've found our starting point and we can now advance down the path to a good refactor.

When Should I Refactor?

This is actually the most important question of them all. You need to be very sensitive about when to refactor because ideally we'd all looove to sit and refactor all the time. To make the awesomest application with all types of great technological patterns and concepts. However, then you get the coolest, and least functioning application. Also, try explaining to a client why you spent 80% of your time refactoring, they love to hear it. I find the best thing to do is simply ONLY refactor when you are already “there.” When you're in the midst of the smelly code. When you are working on something related to something else and you know a great way to tie the two together with a single method (or function, geez). You will often pass things by that would be “so better done like this...”, even things written by you six months later. Your best friend in this situation is //TODO:. I allow myself to mark those down, and this way if you, or someone else, happens to work on or with that section they can go to town.

 

How Should I Refactor?

The answer to this that isn't language sensitive is “tentatively.” You don't want to take on a huge task that will take you weeks when you don't have that kind of time on your hands to play with. You shouldn't go wild deleting sections of already functioning code on a whim. Think and plan well, talk out the new muscle you will be adding all the way through. Either with a co-worker, or even to your reflection. Make sure you know the full ramifications of what you're doing. Possible glitches, hiccups, and bugs. Make sure what you are doing is possible. Be prepared, be educated fully, and as always have fun with it. Refactoring is a powerful tool and once you get the hang of it refactoring will be you (and your project manager's) best friend.