Java Refactoring and Skills Sharpening

Quite a while back, I was heavily involved in a Java project with a stunningly large codebase.  Portions of the code were fantastic and dealt with complicated errors in impressive ways.  The level of design and thought that went into the process was evident by the flow and the handling.  Other portions of the code were just bad.  There are numerous magic numbers, implicit understandings, and fields being misused to represent multiple things.  Although my official involvement with development has ended – they brought development in house, I am still answering various questions and offering clarifications for the new development team, so I still have my hands and mind in the code.  Since I'm already familiar with the codebase, I thought I would improve my refactoring skills and see what happens.

There is no intention or legal ability to release the results of this work.  This is simply an exercise to sharpen and review various skills.

First, I started writing some more Unit Tests.  I believe firmly that you don't have true understanding of the code until you know where it works and where it breaks.  Besides, it's hard to know exactly what to expect from the code if you don't know precisely how it's supposed to work.  Previously I had developed Unit Tests throughout much of the Utils sorts of classes, but now I'm moving up the stack.  I don't know how far up the stack I'll end up climbing, but it's educational regardless.

Next, I've started hammering on it with PMD to get some additional metrics.  I've written all about PMD before and have already used it to analyze this codebase with a specific set of rules.  This time I've expanded the ruleset and added a few to experiment with the results.  While Tom Copeland is often focused on reducing the size of the compiled classes, that's a secondary goal here, so if it happens, great.  If not, no worries.  One more note about PMD…  don't ever turn on all the rulesets at once.  Some of them are directly contradictory and focus on coding style as opposed to function.  You'll end up following the suggestion of a warning in one place only to get a new warning recommending the opposite.

Finally, I've pulled my Refactoring books off the shelf to review.  I fly through nearly anything I read and have a high retention rate but that fades over time.  So every so often, I have to review  this sort of stuff.  Besides, as my experience and knowledge has grown in areas of different business domains, different toolsets, and different developers, I've found that I think and analyze things in new ways.  Therefore every time I review, I discover something new and a new way of looking at things.

What do you do sharpen your skills?  How often do you do it?