There is some best practices that you should do but the best advice it's to follow the SRP (Single Responsability Principle) that states that only one class should have one single responsability, or if is have multiple responsabilities that one should be related to the class itself; it simple states that you shouldn't mix stuff that doesn't make sense in classes.

You should use the module approach in any application you do (that not applies only to game simulations).

Actually if you're using module approach you're already using the SRP in the context of your architecture; each module it's responsable of one thing; such thing can be a physics library, a graphics library, a file system library, memory library. etc.

There is tons of optimizations that could be don once the program is created and that not applies only to C++; C++ is a language that should be used to make games, more specificly to make games run faster and have full control of its flow.

There's no performace "tips and tricks" for a single thing. There is a milion of performace optimizations that are allowed to do in a specific case but that not applies to any type of project; you shouldn't have even think of optimizing a graphics module if you don't know how the GPU works.

Such "tips and tricks" depends pretty much of what you're doing.

This type of thing requires experience.

People gain experience in two main ways:

1. Reading about other people's experiences, then reasoning and learning from them.

2. Making mistakes and gaining your own experiences, then reasoning and learning from them.

Reading for the first route only takes you so far. You will read some things, but you will be limited to the things you have read about.

The second route is also very effective. Make mistakes. Lots of them. Show it off and ask other people for feedback. When they tell you something is bad or problematic, take notes. When something is annoying to you in your own systems, also make notes.

The second route is also very effective. Make mistakes. Lots of them. Show it off and ask other people for feedback. When they tell you something is bad or problematic, take notes. When something is annoying to you in your own systems, also make notes.

One person I worked on had a fun philosophy on making mistakes.

Junior engineers should make a lot of tiny mistakes. If their code isn't buggy that is suspicious. Everyone should review their code.

Mid-level engineers should make some mistakes, but less often. The mistakes they make should occasionally take down the entire team's productivity.

Senior engineers should rarely make big mistakes, but when they do, they ought to be incredible. A senior engineer might occasionally break something for 100 people, then all the engineering team can review the single change yet have nobody be able to identify what broke even though the code is right in front of them.

If you are a senior engineer and you aren't at least occasionally causing disruptions with your "experience gaining" events, you are slacking off and need to be more aggressive in your work.

While developers should aim for solid, reliable code, it is unrealistic to assume developers will write perfect code every day. Do you best, but push yourself.