Seeking Tools, Tips, Techniques to learn a new application quickly (from a coding perspective)_问答_开发者

I'm a software development consultant looking for some tools to help me quickly understand a new application when I begin a new project at a customer site. The sort of things i think would be useful to get a high level overview of the application or system would be DB Schema diagrams, Domain object model diagrams, UML diagrams, API, etc. Basically things that give me a high level overview of the product, and how to work with the application from a developers stand point. Right now I'm using object browser in visual studio, but feel like there should be better and more options for this sort of thing. I did use a tool called Doc-O-Matic and it gave me some idea of the relationship of the class files in the C# solution.

My current project is a large & complicated application written in C#, Spring.net, NHibernate, MVC and I'm trying to get my head around the design. It seems very sophisticated and heavily uses OO design patterns, and things are very abstracted which makes it harder to follow what the application is doing (although I'm sure it's designed well from an OO perspective).

What sorts of tools, techniques a开发者_Python百科re available to help me get this kind of information in situations where little to no documentaiton is provided by the customer (as is often the case)? What tools, tricks do you use to learn a new system quickly?

Thanks!

You (at least I) can't learn the whole system design and how it's working. It's too time consuming. I once faced the same problem when I started my job., though I had a large project that wasn't that nicely designed. Some steps to get quickly to action are:

Learn how the application is working from the user's point of view, that means use the application in the areas you have to work on
When you are familiar with the problem domain and know what business cases are addressed in the application, then move on to the module/part of code that you have to work on.
The best would be to get a kick-start from a (former) developer. If you don't have anyone to do this, try to debug the process/code you have to change, so you can see the involved components.
Start with the smallest use-case possible. If the application is well designed, then chances are very high that the same patterns have been applied all over the code. So, if you "crack" one piece of code, you get 'em all (... at least the design logic part).
Write down things once you understood them, else you will forget them due to the big amount of information you are gathering in a short time.
It would be also good to comment the code where it is lacking documentation, but that is a dangerous thing if you are working the first time with the application. You will encounter situations where you thought that you understood what was going on, but you didn't.

That's just some experiences I have made.

First off, don't immediately assume that a program which is hard to follow is "well-architected from an OO standpoint". The purpose of OOA&D is nothing more or less than to make code easier to understand, extend and refactor, by avoiding "spaghetti code" (code with large disorganized files containing lots of jumps; pretty much the only way it could be done in older languages). However, you can, with overzealous use of design patterns, architect other programming pastas: "lasagna code" (so many layers of abstraction it's difficult to dig down to the actual code you want to inspect) or "ravioli code" (code is broken up into so many bite-size chunks that you're constantly moving from file to file to trace the execution of a single simple algorithm).

Anyway, for .NET projects, VS has some tools to generate class diagrams. Office Visio Professional can also integrate with Visual Studio and extends this functionality, allowing some "back and forth" between changing diagrams and changing actual code. Similarly, it can plug into MSS and give you schema diagrams. But, there's really no tool better than hands-on experience. Even the most well-designed code will have some idiosyncrasies that require you to know the codebase in order to zero in on the object with the problem (or the relationship between objects, etc). I have not yet met an employer who didn't expect it to take at least a month for a new hire to familiarize himself with enough of the current architecture to begin to be productive. From a contracting perspective, that expectation may be less lenient, but it's simply unreasonable to expect someone to dive into a massive codebase with little or no external documentation and start swimming like an Olympic sprinter.