[buro9]

Three ways...

1. I go straight to the entry point, the main(), and then follow how the initial configuration, flow of data, sanitisation, and routing is done.

2. I look for bugs. Fixing bugs reveals the complexity as you need to look for side effects of the fixes when you don't yet know the system. Writing tests for those fixes also helps understand the system.

3. I look for the least changed part. I find these are usually the oldest and most core part of how the program works, whereas more recent changes are business logic and feature addition.

But of these, the first yield the greatest initial understanding and allows me to change things with less fear.

[smugma]

How do you think of #1 in the context of a web app? Each page is essentially a different entry point into the code.

I guess the landing page or authentication page could be considered the equivalent, but I’m not sure those would hit your goals to understand flow of data, etc. ?

[muzani]

Yup, I've stopped looking for the entry point in SPAs and apps. Often the navigation flow can be extremely convuluted.

Android introduced navigation graphs [1], which were meant to solve this problem. But what happened in reality were instead of arrows point to each screens, there would be multiple islands that were teleported in from random places.

[1] https://developer.android.com/guide/navigation/navigation-ge...

[buro9]

It makes even more sense for web apps. It will tell you how it came to be that a web page received the request, what context it has, how the cookie is resolved to an auth context, how to access any query args, what is available to support the page.

[tedmiston]

These are great.

A 4th way I would add is: If you need to make a minor change or understand how one specific function is expected to work, search for its unit tests and start there.

[gompertz]

#1 is my method too. I also take it as a sign learning the code base is going to be difficult if I have to ripgrep to find main because they couldn't put it in a cleanly named file like main.c =)

[jarusll]

1st is exactly what I do while reminding myself that I don't need to understand everything. Somehow for me it's easy to think like that in OO code and not FP.