What is the fastest way to understand an entire project?

>>59660132
>>enterprise project
>>no documentation
Sounds about right. Run while you still can.

Debug it.

>>59660132
Hope your ide is a powerful one.

>>59660252
Why would you say that?

>>59660169
>implying i have a year to burn

Is there a fundamentally accepted way of understanding a huge software project?

Pick a bug, fix it, repeat. Eventually you'll have a good understanding of how the app works. Without a standardized framework or documentation, this is your only way.

>>59660132
Try to understand the dependencies graph.

>>59660132
What enterprise project has documentation?

Better start reading all of the fucking code

>>59660132
What platform? For example, Visual Studio has some great project visualization tools that will show class dependencies and stuff.

Though be warned, if the project is big enough you will never understand it fully. Either you get too stuck in the details and miss the overall flow, or you get the big picture but miss the particularities of each part. Don't worry, chances are nobody knows it completely either.

Your best bet is to read whatever documentation is there, and get your hands on it, do >>59660476

>>59660132
Do this >>59660476 and write down your findings as you go. Also keep in mind that the existing documentation and comments in the code don't compile. Assume that they're outdated at best and outright lies at worst.

>>59660132
>enterprise project
>no documentation

Is there at least some decent commenting in the code?

>>59660132
Are you the only engineer working on this project? If not, the best way to learn is to have someone more familiar mentor you, and for you to write documentation as you learn so that the mentorship actually provides a major benefit to the project in the long term, for all future engineers, not just you. I suggest doc comments of some sort, documentation being tied to code encourages engineers to keep everything up to date, and makes it easy to notice failures to do so in code review.

Otherwise, go from high level to low level. Start with the overall function of the project, then any frameworks / paradigms you're unfamiliar with, then the API surface of all the major components, then the architecture of each component, etc.

This way, you can use your experience to make guesses about the next level down (if I had to do X, I'd write the API this way; if I had to implement this API, I'd structure the implementation this way, etc). Then you only need to learn how and why they did things differently from what you would have expected.

Only go as deep as needed, if possible. If the project can be divided into pieces that aren't absurdly tightly coupled, you should be ready to write useful code far before you understand every line of any part of the project, and even before you understand the architecture of each major component.

If the project is a clusterfuck of spaghetti code, then you're basically screwed and you'll have to do what you can.

>>59660132
leaving 4chan and working on the said project

>>59660966
>>enterprise project
>>no documentation
It's like that everywhere.