Software Archeology was the topic of the presentation given by Michael Rozlog of Embarcadero Technologies at this month’s meeting of the Columbus Architecture Group. As a software developer, you sometimes inherit code that you had nothing to do with creating. This can happen for a variety of reasons but the end result is you have a big lump of code that you know little to nothing about. As Michael described it, that code is effectively locked until you take steps to discover how it works. Michael described following aspects of “unlocking” an unfamiliar codebase using software tools and showed some examples using JBuilder:
- Visualization using a modeling tool that can map existing code.
- Using a metrics tool to find design violations.
- Using an auditing tool to find style violations.
- Reviewing business logic (unit tests, acceptance tests – if you’re lucky enough to have inherited those too).
- Using a profiling tool to find areas in the code with performance problems.
- Creating documentation so future maintainers will not have to start from scratch.
From my experience, sometimes you don’t have modeling, auditing, or metrics tools available for a particular system. You just have to grab a shovel and start digging up bones. Make a copy of the code and do some throw-away refactoring (that code will never be checked back into source control). Try to break parts of the system and see if it breaks in the way you expect. Try to come up with some big picture tests that can be automated. Later, when you know more about the system and are ready to start fixing bugs and adding features, you can add unit tests around just the parts you are going to change. Though some environments just don’t support unit tests, but I digress (as usual).
I have a small company background and at this point I’ve never worked with a system approaching a million lines of code. I’m sure there are systems too large to explore manually that can only be discovered using a tool suite that’s up to the task. Nonetheless, I am reminded by Michael’s examples at this meeting, if you have the tools available you should use them, even for a small system, even for your own code that you think you know well. You’re bound to learn something, and make your code better in the process.
Also in my notes from the meeting:
Stupid iPhone apps can make a lot of money if they go viral.
…and from Microsoft, who provided the meeting space: