Dr. Strangecode. Or: How I Learned to Stop Worrying and Love the Legacy

DZone 's Guide to

Dr. Strangecode. Or: How I Learned to Stop Worrying and Love the Legacy

· Agile Zone ·
Free Resource
Someone recently asked me what technologies I would recommend for the next Enterprise Web Project. Like a good little software developer, my initial reaction was "I would have to see the requirements first". And of course that is true. As much as possible I try to fight the tendency to fit requirements around the technology, because I know that I am wont to be enamoured by the latest shiny thing in the software world.

But even though I have no idea what my next job will be, I already know what it is. It will be another Java/Spring/Hibernate enterprise web application for a government department or medium sized corporation, probably replacing one or more existing systems. That is what people want, and that is what I am good at doing.

The software nerd in me is repulsed by these things. I would love nothing more than to write my next enterprise web app in Javascript with a NoSQL database and write server side web services in a pure Functional language, which I feel can more directly solve the enterprise problems I have been confronted with in my career so far. But the corporate world is simply not politically or culturally ready for it. I can accept and respect that.

So let's get on with the business of writing good Java Web Apps.

Something I have come to observe is that ALL code is legacy code. The moment somebody else looks at it, it is legacy code. Right now, somebody is probably working with my lovingly handcrafted feats of software engineering (in my mind) and thinking "Man, what was this guy on? grumble grumble legacy code..."

So my reasoning goes like this: I love my own code; all of my code is legacy code; therefore I love legacy code.

How can I make the legacy code that I write as painless as possible for the next guy? Here are some of my favourite techniques:

Covert Code Reviews
Management hates pair programming, but every couple of days just give the guy sitting next to you a 5-10 minute tour of the code you have written. You'll have to swallow your pride the first few times, but it will promote consistency in the codebase, which is the single most important attribute of good legacy code.

Automated Code Test Coverage Tools
Set a minimum test coverage percentage that will fail your automated build tool when it dips below that value. This will at the very least promote dialogue (probably heated) between developers.

Style Checking Tools
Like the Test Coverage tools, a set of checkstyle rules that fail the automated build will go a long way towards keeping the codebase consistent.

Frameworks and Code Generation Tools
Yeah I know we love to hate frameworks. But for all the pain they cause us, at least it forces us to write code in defined and consistent way. One shiny thing that I have in mind is Spring Roo, which I really would like to try on a future project.

Get an end-to-end build process
Ideally something that runs nightly, deploys the application to your real application server and runs all of your tests.

Don't live with broken windows
TestNG for example (I'm not picking on TestNG in particular) allows you to create a test annotation called "broken", which permits the build to ignore tests that are temporarily broken for some reason. DO NOT USE THIS TAG! One broken test will quickly become two, then ten then fifty. Soon it becomes normal practice for developers to mark tests as broken, and the malaise sets in.

Use a decent IDE, get 2 monitors, work on a powerful machine
These are essential tools for writing good legacy code. Also, IntelliJ > Eclipse (what good is an opinion piece without some controversy?)

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}