Last night I was in the process of refactoring some of the code in the project I am currently working on. After a while I fired of the following update on twitter

Is refactoring more fun than writing the initial code? It's like putting the finishing details on a piece of art,see it take it's true shape

It did not take long before I got a couple of replies from people agreeing with me. This got me thinking. Refactoring is essentially the same as restructuring your code and to many that is a daunting task, something they would rather try to avoid because of the risk that something might break. I came to the conclusion that there are 6 things that I make sure I follow before and during any refactoring and here they are

1. Make sure you have good suite of tests – Let me be perfectly honest here; if you do not have a good suite of tests in place for the code you are about to refactor, then it is not going to be a pleasant journey, period. Having a suite of tests you know prove that the code is working as intended is going to make you a lot more comfortable with making radical changes to it. They are your primary refactoring safety net, so make sure they are in place. You are going to want to run these tests a lot so take the time to setup keyboard shortcuts to re-running them, you are going to be thankful you did. Re-running your tests should not be a chore, it should be second nature and switching out of code-mode to move the mouse to select the menu option to run the tests are going to start gnawing on your patience pretty quick. If re-running your tests is tedious you will not run them as often as you should.
   
2. Get to know the tools in your toolbox – Most modern development environments have support for the basic refactoring steps, such as renaming, extracting method, reordering parameters and so on. Refactoring can quickly become repetitive and tedious, but it does not have to if you know how to take advantage of the tools at hand. Learning the keyboard shortcuts to perform the basic refactoring steps is going to solve both of these. Take the time to learn the keyboard shortcuts to speed up the process and soon enough code will literally change shape as if magic was involved. Tools such as ReSharper, CodeRush and JustCode brings a lot to the table that and, once you know the tools, it will increase productivity a lot.
   
3. Use a version control system – I can not stress this enough, but being able to reverse the changes you have made can, and will, turn out to be a life-saver more than once. By having your source code under version control you bring instant reversibility into the game and there is no need to worry if you find yourself in a place where the state of the code is horrible. Simply revert the changes you have made and start over from scratch, but with the experience gained and lessons learned from the previous failed attempt. The most widely used version control systems, such are Subversion, Git and Mercurial, are all free, so there are little or no reason not to use them, even if it is just a local repository on your hard drive.
   
4. Keep the iterations small – Part of the agile process is to keep tasks small and the same goes for refactoring. Focus on improving one thing at a time or you are likely to loose track of your changes and end you reducing the quality of your code instead of increasing it. If you (and again, you really should) have your source code under version control, then make it a habit of (at a minimum) committing your changes after each iteration. Break down large tasks into many smaller ones to get a better overview of changed you are making.
   
5. Have a game plan – Do not start refactoring your code without having a game plan. Just randomly trying to improve the quality of your code is to sell yourself short. Take a moment and get a mile-high view of your code, then formulate a game plan. During the initial coding, you probably made notes, mental or in some other form, of points that you would like to revisit later on to improve, start from there. Having a game plan enables you to define the confines of the iteration, in other words you will be able to know when your work is done.
   
6. Do not add new behavior – Refactoring is about improving the quality of your code. If you find yourself introducing new behavior then immediately stop. Looking at the refactored code might make it more evident on how additional functionality could be introduced, than if you had looked at the old code. However if you decide to walk down that path you are no longer refactoring, you are now designing a feature and you should revert back to the normal process, such as TDD. The last thing you want to do is to change or add behavior in your code without making sure it is covered by tests.

There you have it, my steps on how to make refactoring into a pleasure instead of a burden. If you have any more steps that you follow, please leave a comment! I would love to hear about them.