First, you are already doing the prerequisites by taking classes, reading reference material, looking at open source projects, and staying curious with questions. I stress this because I've personally encountered similar questions before the person has done any leg work on their part (specifically, individuals circumventing classes and hoping to take short-cuts). Now, I think back to when we had labs about Turing machines and how at the time I felt it wasn't real programming. These are the experiences you will keep that anyone taking short-cuts is skipping.
Sign-up for student projects. I got involved with (CSUA) a group of like-minded students to build a game for the carnival booth my senior year. If you continue to enjoy it and think you want to expand your involvement, really take advantage of resources. Find out about projects, talk to your class mates, your professors, and land an internship.
Sit with an experienced programmer. There has been about three times in my history when I watched another person program that was truly inspirational. To them, they were just writing code and thinking out loud. No exaggeration, I felt like I absorbed more from listening to them than I would years on my own. If you encounter more, you are that much richer. We are lucky to be in an age where we can watch videos, inspect complete source repositories, and search a huge online store of knowledge instantaneously. It's no substitute to the in-person experience, but in the absence of a mentor it's a dramatic improvement over traditional material. Looking at raw code by others by itself may not lead to anything, though. You will want to have something in mind and a good debugger to step into logic. One of my fondest moments was making a Quake mod and it wasn't the mod itself that had anything memorable. It was seeing Carmack's in-game logic. The mod was just a reason for me to dive in.
Practice explaining and answering questions posed by your lab partner. Volunteer to help teach. Maybe form a study group and require each member become an expert on a class topic. Then grill that person and have them grill you. When you are forced to answer questions, you will be obligated to learn the answers yourself. When you can explain concepts clearly to others, you have enriched your own understanding to the point where you are able to convey it outside of a book and your thoughts.
Last, don't be afraid of learning the hard way, get your hands dirty, make mistakes. This can also be called experience. As a more practical example with regards to your question about projects with unwieldy code base and large file number counts, do this exercise: use a single file for your work. Really I'm not joking. This very same question actually came up at my current and previous company. Here another developer observed that I prefer to keep one file for each class. This seemed foreign to him and, in a related matter, he also did not like partial classes. So one way for you to get a sense of when or where it's appropriate to split up logic into separate files would be to begin with just a single file. After you have practiced the one file rule on multiple projects hopefully of increasing complexity, you may run into a project where you have so many classes in the one file that you find it difficult to read or due to version control becomes difficult to collaborate. At this point, you want to create separate files to group different classes. Given your preference, you may decide early that you like all data classes in one file. Then again perhaps later, you may decide that you like separate files even between data classes as a group.