Here's an example of someone going through a good process of structuring code: Casey Muratori: Working on The Witness, Part 11

The essence is to just write the code to do exactly what you need it to do at first. Then refactor as you go, whenever you see opportunities for code reuse. The data structures and code structure that will result will probably fit your needs quite appropriately, rather than being ill-suited in the way that unfortunately often happens with up-front design.

1. Keep it simple
   If you need a feature once, write it the simplest way possible. If it turns out that you need that feature over and over, only then should you refactor it into a generic solution.
2. Don't be afraid to refactor
   If you find your the design/API of earlier components are causing problems later on, refactor them to make more sense. You know more about how the system fits together now, than you did when you wrote it the first time.
3. Prototype often
   Get features in a rough form first, so that you can see if they work well in the system. If they aren't, go back to the drawing board before you invest too much time.
4. Work with others
   Having someone else work on the same codebase (and review each other's code) is a great way to keep the code clean. You will each be accountable to someone other than yourself, and you both need to be able to understand the code.

Its kind of a skill that can only be developed through practice and experience. Over time you'll develop a sixth sense about code and code structures that are bad now and only going to get worse if they stay as they are.

As some guidelines --

Keep things simple: Start by only implementing functionality you need. The only thing worse that building the wrong thing early is building a *lot* of the wrong thing early. This also helps stop you from building things without having need-driven requirements.

Follow the DRY (Don't Repeat Yourself) principle -- Whenever you write the same code more than once, its a candidate for becoming a function. Especially now that most languages support some kind of lambda function, you can easily factor out common code, even if its never useful outside of one function.

Prototype and explore -- Even people with a lot of experience don't just get things right from the git-go; Everyone builds little prototypes, redesigns, and refactors pretty aggressively.

Seek critique: Its hard to learn by reading other people's code, especially when you're too green yourself to evaluate its quality. Better for someone with less experience is to submit your code for commentary -- by those with real experience -- and to take their suggestions and implement them in your code.

My code uses classes. Should I have classes with the same variables? Is this simple?

This question makes me think that maybe you're really green, and need to spend some time concentrating on learning programming fundamentals. But I'll try to give an example.

A class is a kind of cookie-cutter, its not the cookie itself -- Imagine that you're making a Pong clone. You don't create two paddle classes, one for each player -- instead, you create one paddle class, and then you realize two of them (two "instances" of the class), assigning one for each player. The ball might be a separate class -- even though there's just one, you still create the ball class and then realize a single one (just one "instance"). Now, say, you want to spice things up with a crazy, 3-ball sudden-death tie-breaker. Because you have a ball class, you can just create two more instances. But doing so might expose places in your code where you assumed there would only ever be one ball -- *the* ball -- and so you will have to take that existing code and change it to work with multiple balls. This is refactoring, and its perfectly normal. With experience, you'll begin to see opportunities to build this kind of flexibility into your code before you need it -- this kind of flexibilty, driven by opportunity rather than kitchen-sink-thinking, is usually good -- good code is flexible in these kinds of ways. However, beware of adding unnecessary flexibility, in keeping with keeping things simple.

My code uses classes. Should I have classes with the same variables? Is this simple?

this sentence doesn't make sense at all... and that means you are simply still a beginner and your knowledge of programming is not yet at a level where you can actually discuss about these things.

Concentrate to make things work, no matter how ugly they are, you'll make them prettier and reusable later. Keep studying and making games, have a look at some other people's code.. you'll start to see patterns emerging... that's all that it is: just experience.