While it's not for everybody, take a look at UML. What better way to organize and understand your code then to visually map out all the classes and their relationships. You can download a community version (free) from Visual Paradigm, which has the best UML editor out there (IMO).
As for how you should design your code, that can be pretty subjective. What works for some, might not work out for others. One place to start is to read up on software design patterns. This won't outright solve your problem, but if you read through some of them it will open your mind to how you could potentially implement your solution in a way that's not destructive to your overall codebase. Keep these on hand and if you have the time, build a couple test projects and try them out. Get a feel for them and see how they work first hand. You'll more than likely come across a need for one of them in the future and you'll be happy to have already studied them.
To get you somewhat started on your problem, try not to think of a level as a class. Instead, break down your game into major and minor components. A major component would be rendering graphics, detecting collisions, loading and caching map files and its resources (sounds, textures, polygons), scripting, etc.. Next, break down these major components into minor ones, which are the core of your classes you will implement. You're interested in level rendering and interaction right now. To break this down into minor components, you need to figure out what are the inputs and outputs of your game. What can someone do and see in a level and are there any special considerations. Your final solution should have a set of reusable classes that are fed the exact same data every time, but have a sort of API that your maps can use to perform certain types of actions. Most games implement this as scripting.