Refactoring observations

Its almost spring time and I’ve been doing some spring cleaning both at work and at home. Yes, its refactoring time. For the most part I like refactoring. It’s a chance to go back and tighten up the code, correct earlier guesses, and just make things nicer looking. One thing that has really been hammered home to me is the type of refactoring you are trying to do depends greatly on the underlying design and what you are trying to change about it. Example: One of my home projects is an RPG game written in python. I started out with one code base, and began changing it to meet my ideas/needs. Over time it has change two more times. Yesterday I noticed that a major class (the display that draws the tiles to the screen) had not really been migrated and could use some attention. As I began trying to work in the new changes I saw why I put the project down a few months ago: there’s got to be some major changes because the class is so different than the new architecture. As a result, most of the refactoring tools/techniques I’m used to using (at work) just can’t be used right now. At work, I’ve got a pretty well laid out architecture (coded in Java) and most of my refactoring work revolves around streamlining and consolidating methods and classes. The refactoring tools in Eclipse make this a breeze because everything is pretty straightforward. (Also, the strong typing of Java is really helpful in this area, its much easier for Eclipse to figure out what a member variable is in Java than it is in Python.) The moral of the story? I think it’s best to make sure you build in some flexibility to your designs. This will allow you more choices down the road, especially as you discover new techniques for your particular language. As always, the tools are helpful, but they can only do so much to help you.