I am self taught and I am trying to follow more advanced tutorials. Although I understand each line of code individually, I don’t understand the bigger picture as there is often 10+ scripts all feeding and inheriting from one another – its really hard to understand the flow.
I am currently reviewing the code script by script, but I still feel the bigger picture go over my head as I struggle to follow how information is being sent across different scripts.
Then I thought, there will be professionals who were in this exact position when they started a new job! And it would be way more stressful as its your livelihood. So, how did you guys quickly get up to speed – how would you approach this?
I tried diagrams, but it didn’t really ‘click’ that way either.
EDIT: This is just a hypothetical as someone who is following more advanced c# tutorials. So sadly I can’t ask the team for direction. I am just trying to understand how to quickly get up to speed with unfamiliar and slightly more complex scripts when you feel overwhelmed with how information is moving.
I find the killer skill for a developer is the ability to not be distracted/overwhelmed by the application as a whole and just be able to quickly filter down to what’s needed to solve a particular problem.
I think it’s easier to work on some “beginner” user stories and be laser focused on that work. Simple bugfixes, etc. Understand enough of the application to be able to work on that story, and of course, lean on the rest of the team as you do this. As time goes on, you take on more and more complex stories/features and you’ll build that knowledge of the whole.
In the “forest” that is the application, learn how a few of the “trees” work by doing more simple work, and over time gradually build up that knowledge.
It really helps to tell people which kind of application you’re working with: WinForms? WPF? Xamarin? ASP .NET Core? A console application? All of these have different ways they’re put together and that means the way you tackle understanding them is a little different.
For example, even a very simple ASP .NET Core application is likely to use the host builder framework to set up an IoC container, logging, database credentials, and a number of other things. While that’s useful, it doesn’t point an arrow at “what code runs when I hit an endpooint?” To know that, you have to figure out how it configures routing so you can figure out how URLs map to Controllers. From there, View <-> Controller mapping usually guides the way.
But a WPF application might not use IoC at all. It could be a novice-style application that eschews MVVM. It could use an MVVM framework. Knowing which one might help you find documentation that’d explain how the app is put together. But just like in the ASP .NET Core application, your goal is to figure out how to connect “this is on the screen” to “this is the XAML/code that represents it”.
Figuring that part out will give you some ability to start finding out where the code that does certain things lives. For example, on some login screen, clicking the “Login” button results in some code running. If you want to know, “How does the login feature work?”, the best place to start is there. It probably uses some other classes, so you can go look at them and see how they work.
I use a notebook and a pencil to do this kind of work. I like to think of many applications as sort of like a text adventure game. My goal is to write something like:
“The Login screen is displayed at startup. The user can use it to log in. It depends on ILoginService to do this, and upon successful login will navigate to the Dashboard screen. If login fails, no navigation happens.”
That’d also lead me to make some other page about what ILoginService is, what it depends on, and what it does.
I’ll do that for each screen/endpoint. Yep, it’s slow. A lot of times I find people appreciate it because you’ll end up documenting stuff nobody ever took the time to document.
This goes a little faster if they give you actual issues to work on. Then, instead of starting at the first screen/endpoint and working your way through all of them, you can focus on just the one you care about. It probably depends on stuff that was created before you got there, so go backwards through the code: who navigates to this screen? Can you find the code that does that? What data does it create immediately before that navigation? Etc.
That’s really it. Find a part of the program you want to know more about and walk through its methods. What do they need to function? How do those things work, and how does it get those things? That’s “all” there really is to understanding everything from individual components to the larger constructs that coordinate those opponents.
There are two ways I go about this for new projects:
read their tests
if they don’t have tests, quit.
Ok, that was a joke.
Typically, if it’s written to any kind of standards, they’ll be doing IoC. This makes it fairly easy to figure out what needs what. From then it’s just starting from Startup.cs (etc) and seeing what services they’ve created using what interfaces. Also, if it’s a web API (etc) you could start looking from the controllers as that’s the user’s entrypoint. If it’s a GUI app (WinForms/WPF/etc) start with the forms. Basically, in most cases, start with the user’s entrypoint and work your way down. Unless they have tests, in that case you could just read them.
Ehh, what are tests?
I am just following tutorials, so there is no formal documentation if that is what that means, just the videos and the scripts that I have typed up from them.
Also, 0. ask the person that knows what it is and what it does.
Personally, I make a private copy of the code, and then go through it line-by-line, changing any too-short or abbreviated-variables, one at a time, then compiling after each change.
That helps me understand (relatively quickly, for me, at least) how the app operates and are what the major functions.
** Just make 100% sure that you preserve copies of the original code so you can start over if you make too many changes or make a change you don’t understand – anything the suddenly makes the app NOT compile.
If you need to crunch, open the first file as the program runs. For a web project this will be startup.cs. for other projects, just find the entry. Then, as you step through the code to read it, keep the tabs open in order.
If you just need to get an idea, find work to do on it, and learn it by creating new features or fixing bugs
C# devs
null reference exceptions