| There's no right answer I guess. It really depends on what you're doing. For me if I'm starting a project and I have no idea how to structure it I'll typically look for some simple example projects which do something similar. So if you're looking to build a small game with say the Phaser framework then you could just Google "phaser example games" and look for some projects that you think are structured well. Other than that it's mostly just about splitting up code into smaller reusable modules. If you're finding your code hard maintain that's generally a sign that you need to break it down into smaller components that can be reasoned about easier. I think one of my strengths as a developer is that I'm kinda dumb and have really bad memory, therefore I have to simplify everything just to get thing done. Another thing I see devs do wrong a lot is that they tend to want to extend existing code too much. The reason for this is obvious, generally it's quicker and easier to add an extra parameter to an existing method rather than taking a step back to think about how to add the functionality without increasing complexity of any given method / component. But if you keep adding parameters and extra logic eventually you end up with something that's extremely complex and hard to maintain. I find if I just focus on reducing state and the number of parameters I'm passing between methods as much as possible then I'm forced into good patterns. It's also worth just taking a step back from time to time and thinking about the high-level architecture of your project. As a project develops and grows in complexity there are times where you might need to make larger changes to keep things maintainable. This might not be the case for you if you're just working on smaller projects, but there are times where it can make sense to split projects up into smaller services. |