13

Possible Duplicate:
When is a BIG Rewrite the answer?

I'm on a small team that's been handed a poorly-written, half-finished 2D Java game. Our objective is to do as much as we can to make it better in about 11 weeks. I'm pretty sure the code is not maintainable and I need to decide if I should pitch the idea of a rewrite (near rewrite, anyway).

For example, the Main class, which is an applet, has most of the game logic just thrown into it. Keyboard and mouse events are handled with huge if/else blocks, none of it is commented (the only comments are the sections of code that have been commented out), and all of the drawing and animation code is just in one huge chunk. Images are loaded in a separate class that just goes through each file, each on a separate line, and reads the image into a static Image variable. This all seems like poor design.

We have until the end of the semester, roughly 11 weeks, to make the game better than it is right now. It's playable but severely broken in spots. I've currently been assigned a small feature to implement: a clickable main menu instead of one that's controllable by keyboard only. On one hand I know I'm capable of implementing this but on the other I'm afraid to try to add new features because a) the more stuff we add the more likely it is that the program will break because of the bad design choices and b) the more I'll be adding to the mess that's already there.

I took the weekend to try to duplicate the basic game functionality with a different design (to see if it could be done quickly enough). I'm able to load and cache sprites, create game entities and move them, and keep track of the game's state to determine which keyboard input to handle and what to draw on-screen. A spritesheet loader was next on my list (I found out that the game art isn't in sprite sheets but each is in a separate file). A trusted friend said that it might be better to have to maintain the old code but looking at it it's too brittle. We could refactor as we go but I think that would be difficult too.

Our group is meeting this Friday. I planned to discuss the idea of an overhaul and present what I've been working on but now I'm not so sure. I feel like it's a simple-enough 2D Java game that once we put together a solid base that it would be a lot easier to add features but we'd have to redesign the base code pretty quickly, probably in two to four weeks or thereabouts. I'd like to think that we can do it that fast but I'm not completely sure.

I guess you could reduce my question down to this: how do you best determine when to maintain poorly-designed code and when to spend some time starting almost completely from scratch?

Community
  • 1
offbyone
  • 131
  • 1
  • 4
  • 3
    `I apologize for penning a novel.` No need for that, instead remove every irrelevant information from the question. – yannis Feb 02 '12 at 06:43
  • 1
    "I guess you could reduce my question down to this". If that's the case, then please remove the irrelevant junk and reduce the question to the essentials. – S.Lott Feb 02 '12 at 10:46
  • 1
    If you only have 11 weeks to finish. What happens if you do not finish? Since this is a class project I am going to assume there isn't a way to extend the deadline. What do you care if its maintainable beyond the 11 weeks? If you run into a problem trying to implement something ONLY THEN should you attempt to address the problem. If this is a college project you do not have the experience required to determine if the code is actually that bad ( you really don't ). – Ramhound Feb 02 '12 at 12:42

5 Answers5

26

Refactor the existing source code. I know it sucks but if there's a lesson I've learned in development its that you don't just throw away a working project because the code is terrible.

Your game is working. Keep it that way.

  • Keyboard events are being handled in gigantic if blocks? Spin that off into a class and segregate functionality into methods. You'll be able to reuse most of the code that's been written already.

  • There aren't any comments? Add them as you refactor specific areas of the code base.

  • The game isn't using spritesheets? Doesn't have a manager? Concatenate the existing sprites into a sheets and write the manager so that it slots into the existing sprite loading solution.

  • Drawing and animation are being all mixed in with the game logic? Again, start moving these chunks into their respective classes.

You get my point. There's nothing worse and more depressing than having to untangle a snarled code base but the victory is that much sweeter at the end. Instead of spending 5 weeks rewriting what's already done, you'll have 5 extra weeks to spit and polish and add new features.

Sit down with your team and map out what still needs to be achieved with this project in terms of features. After you have a comprehensive list you can begin making deliberate refactorings that will directly benefit the success of your project.

Jarrod Nettles
  • 6,125
  • 2
  • 41
  • 45
7

The situation you are describing is the same situation you will meet everywhere in the industry concerning so called legacy-code. To get a notion why you probably not should start from scratch I suggest you read this nice article from Joel.

http://www.joelonsoftware.com/articles/fog0000000069.html

Furthermore, I suggest to get a copy of Feathers' book "Working effectively with legacy code", which describes a lot of useful practices how to handle your situation.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
4

Don't write it from scratch. Inevitably, there will be logic that you miss in the rewrite, and the exercise of getting deep and dirty in the code will be worthwhile. Find refactoring tools that can aid you. I know it's in Java, but for example, Visual Studio has refactoring tools that let you extract out functions very easily. Maybe you can try Eclipse and its tools, or find a plugin.

Start with extracting out large blocks that seem functionally related. You may identify logic that can be separated out into classes. Find the dependencies and parameterize them (e.g. deglobalize variables). Ultimately, try establishing better structure around the existing code first.

You might not end up with a shining example of OO perfection, but that's not the goal. The goal is to add maintainability to the project such that you can add functionality without blowing a fuse.

Kevin Hsu
  • 1,613
  • 10
  • 11
  • Visual Studio has a few refactoring tools built in, though to get it to the same extent as Netbeans, Eclipse or IntelliJ IDEA you'll need the plugins Resharper or CodeRush. – Spoike Feb 02 '12 at 06:54
1

how do you best determine when to maintain poorly-designed code and when to spend some time starting almost completely from scratch?

When a simplest change would turn into a colossal task*, then it's better to start refactoring it. But never just throw away your old code (read about it in Joel's 10 things you should never do.

* I assumed the code is tested, and without bugs. If you introduce new bugs, then your task is not finished.

BЈовић
  • 13,981
  • 8
  • 61
  • 81
0

Suggest you run a clone detector over the code. This will let you find where duplicated code that can be abstracted is found, and you will be able to form useful absrtractions (e.g., handling mouse events, etc.).

Our CloneDR tool will find blocks of code that match modulo parameters; it essentially proposes subroutines (OK, this is Java, they are called methods) showing you duplicated code and how it can be paramterized.

Ira Baxter
  • 1,910
  • 16
  • 17