Learning a big new codebase
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
If you are lucky to work at a company that has decent documentation practices, read the project documents. To get an overall idea of what a project is about read the specification document. Then read the code description, if there is one. Also, try to follow the flow charts. These are standard documents in medical device design and manufacturing. If you are into database or web design, good luck! :laugh:
It was broke, so I fixed it.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
It's admirable wanting to get involved and commit to an open source project, but my suggestion would be only get involved in a project if it's something you use/reference as part of some other development project you are working on, and there are improvements or fixes that would benefit your own project that you believe would also be of benefit to others.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
Do you know WHAT you want to contribute? If you're just thinking about making some contribution or another you're going to have a difficult time, but if you have something specific in mind try to find just that place where it should be implemented. For example, let's say your contribution is going to be that NodeJS always logs to the console when starting a server. Now you want to find where it is that Node finds your file and runs it. Since it's a command tool try looking for that point of entry, perhaps by searching for some optional parameters. From there find where Node is loading your file, you can do this by following the code in your editor or debugger (I tend to use the debugger as I want to know for sure the code actually runs). You should now be close to where you want to insert your code. When working like that you can make contributions, add to the code, fix bugs, etc. without having to know everything that's going on. I've never actually looked at the NodeJS code, let alone contribute to it, but that's what I would do. P.S. Just for the record, my suggested contribution isn't exactly one we'd want (as we can optionally add it with a single line of code). It's just an example.
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
Go small at first. Follow the code paths from UI to the finish line for that particular path. I cannot stress this technique enough. Pick a path that is relevant to your current task or project. Don't try to learn the entire system at one time.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
If a debugger is available, use it to see the call stack, for the functionality you're currently working on. This will give you an idea of the control flow for that functionality. Once the first functionality is reasonably well understood, go to the next functionality, and so on.
-
If you are lucky to work at a company that has decent documentation practices, read the project documents. To get an overall idea of what a project is about read the specification document. Then read the code description, if there is one. Also, try to follow the flow charts. These are standard documents in medical device design and manufacturing. If you are into database or web design, good luck! :laugh:
It was broke, so I fixed it.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
Try reaching out to the dev community, and see if they can suggest easy items for a newcomer to the codebase. I know Mozilla has a list of them, but doubt they're the only project to do so.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
TheOnlyRealTodd wrote:
when I open the project file for these, it can be tough trying to figure out where to even start.
Getting them to compile is the hardest step! :-D
TheOnlyRealTodd wrote:
and also looking at the unit tests to get an idea of whats happening
That's a good approach, especially single stepping through the tests. And write down everything you learn, and your questions for what you don't understand yet. Personally, I think most of these open source sites could benefit greatly from writing some "programmer documentation", as you're not the only one with "how the elephant does this stuff work?" question. And that might be the most useful contribution at first! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
S Houghtelin wrote:
read the project documents
...while keeping in mind that the actual product probably deviates substantially from the original documentation.
dandy72 wrote:
..while keeping in mind that the actual product probably deviates substantially from the original documentation.
Hence the "If you are lucky to work at a company that has decent documentation practices."
It was broke, so I fixed it.
-
dandy72 wrote:
..while keeping in mind that the actual product probably deviates substantially from the original documentation.
Hence the "If you are lucky to work at a company that has decent documentation practices."
It was broke, so I fixed it.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
Play with it without looking at the code, first -- get the grand view, and get to know the whys and wherefores.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
To analyse a large code base you could try running a dependency tool such as DeepEnds
-
If you are lucky to work at a company that has decent documentation practices, read the project documents. To get an overall idea of what a project is about read the specification document. Then read the code description, if there is one. Also, try to follow the flow charts. These are standard documents in medical device design and manufacturing. If you are into database or web design, good luck! :laugh:
It was broke, so I fixed it.
-
To analyse a large code base you could try running a dependency tool such as DeepEnds
Not to be confused with these Depends: Free Incontinence Samples For Men & Women in 2016 | Depend®[^] :)
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
The essence of your learning question is advice as to how you can most efficiently organize and sequence your code-reading-and-understanding learning tasks so as to attain a reasonable level of proficiency in the time you have allotted and at the same time reduce the time you will spend on the study of code without merit, which frankly is not possible until you have already learned it. My suggestion is to, at the outset, refuse to learn and study code written in throw-away computer languages.
-
dandy72 wrote:
..while keeping in mind that the actual product probably deviates substantially from the original documentation.
Hence the "If you are lucky to work at a company that has decent documentation practices."
It was broke, so I fixed it.
I've been at this for 40 years and have yet to find a company that had more than completely minimal documentation at a level that could help a developer. It has always been a learn-as-you-go process. Most developers do NOT document their work.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
As always, working backwards is a good approach. You can find previously FIXED Items, and review the posted code changes that fixed the item. I would recommend being able to build/test the previous version, and verify the bug. Apply the fix. Verify the bug is gone. If you get decent at that. Then get realistic. It takes approximately 5,000hrs to master a new skill. Assuming you have mastered programming in general, lets assume a large code base will take you about 1,000hrs for a solid basic understanding. (Half a work year). Yeah, it is easy to jump in and hack away. But actually mastering a code base. This gets to the REASON others suggest you support a code base that you already use, like, and would like to extend. BTW, as you setup your environment to test/validate prior updates. Considering reviewing and enhancing the documentation that helps others get to where you got to.
-
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub. Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts. Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution? One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
-
I've been at this for 40 years and have yet to find a company that had more than completely minimal documentation at a level that could help a developer. It has always been a learn-as-you-go process. Most developers do NOT document their work.
In the medical device industry if we do not have documentation, you will not be able to sell your device. It is a requirement and for good reason. Would you want to be on the operating table being monitored by devices with software of unknown provenance? "Most developers do NOT document their work." and we wonder why the quality of the software out there sucks. That's called winging it and in my opinion it is unprofessional and if a developer is unable or unwilling to maintain at least some level of documentation I would not be inclined to hire them or to keep them in my employ.
It was broke, so I fixed it.
