views:

108

answers:

6

This seems to be a popular complaint on many programmer forums so I wouldn't be surprised if this question was already on here. Sorry if it has already been answered but I've searched and couldn't find one that relates to Java/OO.

I have a somewhat complicated application that was written a number of months ago. It works well, but is slow and the code is extremely ugly. Classes are split up for no logical reason, half the UI is in the logic code and it's really frustratingly built. I want to redesign and redevelop this program to the correct design standards, yet I don't want to break it completely. There's no design documents, no documentation, nothing but the code (with no formatting) and the built application.

What's the best way of taking an existing Java project, written in the most annoying way possible and redeveloping it in the best way possible? Are there any good tools that'll help me find speed bottlenecks or for extensive testing in NetBeans? Any help for a total novice of testing would be greatly appreciated.

EDIT: You're correct when saying that we don't really understand this program. It does what we want, but it also does other things and we're not exactly aware of, like creating strange graphics and weird numbers appearing on the UI. The main reason we want this redesigned is so that we can actually find out what's going on, but as I've said the code is so messy you'd think it was written by a genius that didn't want us to find out his secrets.

+3  A: 

"with no formatting"

Netbeans has an automatic formatter option in the "Source" menu. That would be a good start.

"There's no design documents, no documentation, nothing but the code"

As you work out what parts do, it will serve you well (and your successors) to document this. That way you will start having documentation you can refer to.

Using JUnit to start adding some Unit Tests to sections before you refactor them wouldn't hurt either.

"I want to redesign and redevelop this program to the correct design standards, yet I don't want to break it completely."

Start small. Work out some simple things that could be designed better and concentrate on them first. Using the Refactor ability in Netbeans will help greatly with this. Concentrate on making sure everything that you refactor still works the same (which is why starting out small helps). The more of the small stuff that you clean up, the easier the bigger stuff will be when you come to it.

Also, make sure what you are refactoring is actually an improvement...

Dan McGrath
"Start small" -- and only bite as much as you can chew *works poorly* is better than *doesn't work at all* and, as much fun as it is to make the code pretty (I can't stand almost all the code/designs I see :-), the functional features (and the resources required to meet them) are what count.
pst
+1 for the unit tests, but I'd extend that to system-level (black box) tests too, especially if it is not immediately clear what the application is supposed to do.
Stephen C
A: 

Really the only answer is sweat equity, but some things that can help:

Happy refactoring!

C. Ross
+1  A: 

I would echo C. Ross's comments and add these strategies for common "bad code" scenarios I've dealt with in the past:

  • Code Duplication: The only thing worse than bad code is multiple copies of the same bad code. Get familiar with the entire code base by speed reading it (get it's flavour) and identify instances of cutting-and-pasting code. Refactor those to a single implementation and remove the duplication. That may be it - or you can continue to refine the single copy of that code.

  • Don't be in a hurry to fix it: Only clean up code that you actively need to maintain and/or understand. This is a variation of if it ain't broke don't fix it I like to call if you don't need to change it don't fix it. But, anytime you need to touch a piece of code take 10 extra minutes to clean it up. Maybe that's just adding formatting it, adding some inline comments, renaming variables to make sense, etc. Any code you need to update will most likely be revisted again in the future, and now you've made it all clean. Code you haven't had to actually change yet can remain ugly without harming anything.

Good luck :)

Kevin O'Donnell
A: 

What you have is essentially a prototype. Tell your manager that that is what it is, and that it should be rewritten to reach production quality.

Thorbjørn Ravn Andersen
+1  A: 

As already mentioned, an ugly code can be cleaned up by a monkey with a proper IDE so I wouldn't go to your manager with that argument alone.

Being pragmatic, I would go with:

  1. grab some tools (a profiler, code duplication tools) to find a couple of pain points
  2. for each point, come up with a battle plan how to solve it (with short specification, design, maybe code sample, test cases...).
  3. go to your manager and let him decide which one to tackle first

The danger is to do too much and to try to clean everything. Depending on the size of the application, it may take years to clean it up (because you won't do this full time) so just be patient.

And of course, when you revisit part of the code, just clean it up with your favorite IDE.

Vladimir
A: 

JProfiler is excellent, I was using it just yesterday in fact to find a performance bottleneck in some Java code I had.

If you can get some automated tests in place you'll be in a better position to start refactorring as you can then assetr that it's still functioning as expected. Specifically you should focus I think on very high level tests of the system, if it's a web app take a look at selenium and/or other web app testing frameworks.

Apart from that, be ready to head down a lot of dead ends, try and avoid taking too much change on at once if possible. The more you can break down the largre app into smaller chunks which you can take on one at a time the more succesful you're likely to be. Also, be prepared to accept that some of it may well remain crappy forever, if it ain't broke as they say, don't fix it.

Robin