I'd advise caution here. Since you don't know what you're doing, you're not likely to be able to tell if a game's architecture is good or not. Almost any non-trivial game that you could find out there is going to have some good architecture and some bad architecture mixed in there, and you're not really going to be able to tell one from the other. That means you could very easily spend a bunch of time learning some terrible practice or some ugly hack that somebody put in that game, assuming it was the "right way" to do things, and be very wrong.
Also, writing any kind of software is this constant balance of tradeoffs. Every step of the way you have to make decisions that usually involves trading pros in one area for cons in another. The areas you will need pros in and the areas some other game needs pros in aren't always the same -- often, in fact. Source code generally lacks the contextual information to identify that such a trade-off has been made, and not knowing that when you read it can negatively color your education.
If you're going to look at other games' code for pedagogical reasons, I'd suggest that you do so after you have written your version of whatever it is you're trying to write. That is, set up your own main loop first and then look at other implementations. Set up your own sprite rendering first, then look at other implementations.
First, this helps you stretch your critical thinking and problem solving skills. It helps you learn how to approach tasks you've never tackled before. Second, this gives you some context about the problem space you can use to make more educated guesses about why other people's code is written the way it was. You may run into a problem in your implementation, solve it, and then see in other code how they solved that problem a different way (where before you might just see some code you didn't understand because you weren't aware of the problem it was addressing) or ignored the problem altogether because it wasn't relevant to the project, or because it was addressed elsewhere in a way it could never be a problem for the code in question.
Stay way from "patterns." Patterns are about vocabulary and having a common parlance. They're not about super-boilerplate solutions you try to shove at every problem you encounter.
