With out being to specific, I've found that breaking things up into many small components works well, not only for games but for general software. The idea is to make many small components (that does only one thing, but it does it very well) that are easier to test and maintain and build something bigger out of them. For example, when making a game, you might want to write a generic lighting system that's totally separate and not coupled with any game code. This component has a simple interface that exposes only a few functions/methods to clients so that its easier to maintain and less breaking when changes are made. Don't embed any specific domain knowledge into the component.
Then you can start putting these components to together to build something bigger. Testing becomes easier and finding out where a bug lives is also easier since there's only one place you'll likely need to look. Try limiting them to only exposing one/two functions.
Also here's a good link more specific to game design: http://stackoverflow.com/questions/1901251/component-based-game-engine-design . Search gamesutra for similar articles since they do talk about similar topics.
I'd also say try being more DRY. If you find a open source library that does what you need, don't write your own and just adopt it. Make changes as necessary and commit to the project if it doesn't meet your needs. Also read books like: clean code. Author talks alot about writing more maintainable code.