The evolution of code

I’m wondering what’s the best way to write good, maintainable, logical code that evolves and adapts as your needs change.

For instance, right now I’m developing a multiplayer game built off JBox2D, but the code originally started off as just a way to see if I could save/load JBox2D Worlds. I showed the program to a few friends and they got excited about the physics and proceeded to generate a lot of good ideas for games that could be created out of it. So I’ve been adding this bit and that bit; right now I’ve got two-player synchronization and a few game mechanics in, but I’m running into problems with attaching game specific data onto the World (I’ve been using a Map<String, String> as my UserData that gets serialized with the Body). Long story short I’m now finding myself re-writing serialization code for my own application-specific classes. It would be much easier to have written wrapper classes for World and Body (and make them implement Serializable) to begin with, but of course at the beginning I didn’t know what direction the program was going to take.

That tends to happen with programs – the more you write code, the more you realize that you need to completely rewrite the code. Is there no other way? One could plan ahead and design classes and abstractions from the beginning to alleviate some of the necessity to re-write code, but sooner or later I always find myself doing a complete overhaul of this part or that part (or every part) of the code. The basic problem is that you never know what direction a project will go in; you can steer it but there will always be new things that pop up – new features, overlooked problems, a change in concept, etc. Is the only solution to overhaul the internal mechanics, again and again? You could possibly write a lot of abstraction barriers to begin with but in general any kind of decision may need to be changed.

One Comment on “The evolution of code”

  1. Samuel Sweet says:

    I guess writing up some sort of planning/design document before you start writing code could help a bit… maybe. My suggestions would be to flush out all the ideas that you want to use, going as deep and specific as you can with them.

    At this point, you could ask for critiques from others if you’re stuck on developing an idea (but if you’re keeping your project private and don’t want to reveal anything, then you’ll have to find a way to keep a few details confidential). When you’re fully confident with what you’ve written down and have a gut feeling there’s probably no more improvement for a certain feature, then it’s time to go code. The difficult part is doing this quickly enough such that the gap between brainstorming/describing ideas and actually implementing them in code isn’t so large.

    Probably one other bit of advice is to make sure encapsulated objects you use in your code are able to interact somehow with as many other objects as possible – even if you think you probably won’t need to interact with all the objects. It may eventually turn out that you WILL need them in the future, as it did in a few small situations with my app.

    I’ve given my app to a few testers and they suggested features that required a bit of overhaul with some of the classes encapsulating several dialogs that pop up, which took some time – so I feel your pain here, for sure.

    However, I would probably take this advice with a grain of salt though since this is coming from a novice programmer. Anyways, good luck.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s