Covering your tracks - let your codebase follow your skills

We've all been in situations when somebody dug up a piece of code from 1997, in a far far away module, authored by us and still containing some not the best of the breed code construction. We've spent too much time catenating Strings instead of StringBuffers, we left behind empty catch blocks, we double-iterated over a map first for the key and then for the value, you name it. We would never do it now, but there were times when we weren't that expert. When it happens there is usually a lot of joy for others when it's spotted, not so cool for us though.

There are several things we can get out of it: first of all if we want to see our programming skills evolving we just need to review our code in chronological order - it's all documented there. Now as we already know how to fix ourselves a nice evening of memories, full of emotions, recalling how fragile and naive developers we were some day, let's think about some more practical aspects of that discovery. Thus the second: people are still running this code and depend on it, and the third – if your portfolio is to be complete it doesn't look to good.

It seems like a good idea to – whenever you learn something new – review your earlier work and update it according to new information you’ve just gathered.

How would you go about that?

You can read the whole code, spot where you used a 'deprecated' technique and replace it with a 'better-new' approach. A single review of such kind may be months to years in time cost depending on how productive you are, and there is a high risk that your manager will beg you to make sure that you will not learn a single thing afterwards.

Then you can use string analyzing tools: simple 'grep' or any other string find software would reduce this time greatly (if you are using home-made one please make sure that you are using StringBuffers for heavily changing strings). You will still get a lot of noise (false positives) and miss a lot of problems (false negatives), which will require a lot of manual analyzing - nevertheless it will be much faster than reading through the whole codebase.

And then there are dedicated tools for that - greps which have kind of regular expressions based on the structure of programming language you work in. That's the fastest I know. Choosing such tool you need to make sure that (one) you are able to integrate it with your work, (two) you can define the pattern you want to find easily, and (three) you are able to define patterns in a way which allows you to reduce noise to minimum (patterns are not to generic (false positives), or too specific (false negatives)).

Once you have such product integrated with you - as soon you learn something new, you can make sure that code you created in the past follows.