How to understand the design and code flow of any product quickly? [closed]

Question

I have switched to a new company and I am working on a product that has a huge code base without documentation. I want to quickly get acquainted with the design and the code flow of the product so that I may become a productive member ASAP

Slowly and steadily one does gets to understand the code, but what should be the best and smart way one should approach the code base so that he understands the code quickly and start delivering?

Note: I tried my hands on Star UML and tried to reverse engineer the class diagrams so that I may have a rough idea of the product internal designs but failed miserably.

EDIT: The question is not about gaining knowledge about what the product does but how the internals are designed.

Fixing bugs and Debugging using breakpoints does provide one way of achieving this but I was looking if there is even a faster way we could achieve this

In Keith's Words:

This may work for some code-bases, but in general I think its a bad idea. You tend to be too focused on the details, while at first you want to get the big picture: what the classes are, what the communication patterns are, etc. Plus, if you have a distributed application (client-server, n-tier, etc), or code that takes a long time to run it may not be practical to run it through a debugger

Answer 1

I'm a contract engineer, and this situation is routine several times per year—for the last few decades.

I find it quite helpful to first run the application and play with it—before looking at any code:

• What the heck does it do? If necessary, read the user documentation.
• What happens with extreme values?
• What if I leave out some values?
• What happens if I click on a control rapidly?
• Is there any way to misuse the program?
• Explore the edges of the application: are there seldom used or hard-to-find sub-menus? Is there a configuration facility which exposes more functionality?

While I'm doing that, I'm constructing a mental model of how I would have implemented it. Surprisingly, this user-oriented first encounter with the product usually causes my understanding of the application to be head and shoulders above the developers who have worked on it for a long time. A side effect of this approach is that I tend to find quite a few bugs (often quite an avalanche of them), and think of quite a few improvements which should be made.

After that, I look at the general structure of the program, whether it be modules, classes, files, or schema. Not looking at individual lines of code, except those showing the program's architecture. Once I think I understand over half of the structure, I try to make a small bug fix or improvement—something which takes a few minutes to write, but may take hours to properly understand. If it works, I make a slightly bigger change somewhere, preferably in another section of the code.

In this way, I've found it possible to understand well enough approximately 50,000 to 100,000 lines of code per day.

Answer 2

If you have a development environment to run the code in the best way I've found is to use a debugger and watch the flow of code while executing it. You can setup break points and step through it to see how the code interacts.

Answer 3

The way I have always learned, besides just reading through the code / data model is to start fixing some bugs. That gives me exposure to various parts of the system, and having the 'purpose' while reading the code makes it a bit more meaningful.