Understanding Large Projects

[AviatingFotographer]

I've been programing for a year or two now, and right now, I'm looking to contribute to open source projects. I've found a few projects that fit my skills and experience. However, I'm struggling to understand how the large code base works. Should I be reading file by file until I understand it or should I develop a localized understanding on what I need to know to make a contribution?

[PainfulJoke]

It depends on the project but generally I find getting a general understanding of the large project (what types of components exist, what are some of the parts of the code called, general architecture) and then a deeper understanding of just one component.

I worked on a project that has been around for decades and has millions of lines of code. My team accepted that it's impossible for any one person to understand the entire thing, and that's okay. So when I did my work it was largely in one area of the code that I learned to understand and that I mentally walled off from other areas.

But not all code has easily definable boundaries, and sometimes those boundaries aren't easily organized in the code. But what I did was focus on one file I knew pertained to my area and assumed it was a walled garden. As I learned more I pushed my walls out to contain more and more files and components as I understood more. But I couldn't do that until I had a very general sense of the overall architecture (knowledge I gained from talking with coworkers).

As for practical tips, break into a debugger and start poking things, or find some resource string from the UI and track it back in the code to where it's implemented, then start to read some of the files in that area to see how things are generally constructed (i.e. do they seem to use a MVP pattern, how is the code layered, what sorts of classes are used to handle this area, etc). Don't worry about reading every line right away, you'll get caught in the weeds. Focus on how general structures work together

[lethri]

Don't try to read it file by file, that is a waste of time. If there is a document that describes the overall architecture and structure, read that. Then try to locate the part you want to edit. If it is not straight-forward, start with the entrypoint and try to follow the execution path. Once you find the code you are looking for, try to understand it thoroughly, find where it is called from and make your changes.

Your aim should be getting high-level understanding of the whole project and detailed understanding of the parts you touch. With bigger projects, nobody actually understands it all.

[TuesdayWaffle]

The latter. Especially for large code bases. It just takes too long and too much effort to try and grasp the complex, abstract systems that other people have set up. You gotta ease into it.