Dr. Strangecode. Or: How I Learned to Stop Worrying and Love the Legacy
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.
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?)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)