The best way to explore/investigate/understand class hierarchy and principle of work of new project

Imagine such situation. You get some legacy code or get some new framework. You need to investigate and understand how to work with this code as soon as possible. There is no chance to ask for help from previous developer. What are the best practices/methods/ways/steps/tools (preferred .NET Framework tools stack) to use to get maximum efficiency in investigating new to you code base.

If it is framework and there is no much documentation and unit tests, what tools you usually use to explore class hierarchy, methods, events? Is it default Object Browser, Architecture Explorer of MS Visu开发者_JS百科al Studio or some other tools like Resharper hierarchy/file view?

---

There really isn't a best way to do this as there are so many variables and every project is different from the next.

To be absolutely honest the best way to get your head around it is to create a sandpit/test environment and, for want of a better description, play with it. Then play with it some more.

As an example of 'playing with it', using debugger and stepping through the code will tell you a lot about the flow and structure of the code. It is also worth mentioning that you should never trust comments, verify functionality yourself. Code may have changed since a comment was written.

---

The best way for diving into a new application with a large code base, the best solution that I've found is to get big picture of it through reverse engineering facility in applications like Enterprise Architect or so. If it's not available to you, try class diagram provided by VS.

So far you can get the static definition of program , but for understanding the flow of execution follow the main scenarios execution path by facilities that you mat find in Resharper, VS2008(generate sequence diagrams, and ...) and VS2010(view call hierarchy and ...).

As said in previous answers debugging and profiling applications is also very helpful, set breakpoints, look at call stack, watch the objects and ....

---

I find that usually the best way to start with a completely unknown code base is just trying to get it to run.

After that, if there are bugs that need to be addressed, try to fix some of those.

That will give you insight into how difficult it is to update/maintain the system. You should also start to see code patterns, or lack thereof, emerge.

---

I often find that unit tests are a good place to start, providing there are some! At least through unit tests you get short examples of how it works, and where is should fail. Hopefully there is some documentation lying about too...

---

In VS2010, there is tool under Architecture which will help you analyze your code base and generate dependency diagram for you.

---

1. Check Project dependencies within a solution. This will give you an idea about the projects flow within a solution
2. Check for the external Dlls used in references. This will tell more information of the system how it is used.
3. Now you can make assumptions now about the flow of the architecture.
4. You can then run the application and Check for some logs which will give you idea about the class and functions flow.
5. You can then start with debugging the code/module which is assigned top you.

This will now put you in better position to now make any changes.