views:

262

answers:

7

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

+2  A: 

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.

controlfreak123
Depending on the setup of your company if you have any QA resources that do testing on the application you could ask them to give some common use cases and testing information so you have a basis to run the program when you debug.
controlfreak123
+1 The first thing I try to do when learning a new system is step through it line-by-line in the debugger.
Jim Anderson
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.
KeithB
+1 Stepping through the code and noting down the important functions in a spreadsheet helps. I usually, organize the entire stack of calls in a spread sheet and try to get a bigger picture.
Sundar
@Keith - You have put my question the correct way which I really want to ask in here. I am stealing your words and putting them down in my question.
Devil Jin
Why is this getting upvotes? The OP says he has a "huge" code base; you could step through it for years and learn virtually nothing. And how do you decide which bits to look at in the first place?
Dipstick
@chrisharris You didn't look at my comment or really read my original answer very closely. If you know how the codebase is typically used you can in fact replicate the flow of execution with debugging. Beyond that you can't cheat reality. If the codebase is huge you can't go from zero to full knowledge without putting the time in. No matter what methodology you use. Some may take longer but nothing replaces experience.
controlfreak123
A: 

Ask everyone you can find for help and ask them to ask anyone else they think could be helpful.

Beth
Please don't do this. Working with people who insist on being spoon-fed all their information is not only extremely frustrating, but kills productivity. Do give it a good effort before resorting to this method, your teammates will thank you. ;)
mpeterson
Asking for help is the fastest, and sometimes the only way to understand what's going on, especially with complex systems. There's no documentation for a reason- they didn't have the time to create it. The knowledge about code is in heads, or not there at all. He needs to learn where the knowledge gaps are he's expected to fill and that comes from asking teammates.
Beth
+2  A: 

Your question seems somewhat similar to this topic

Maybe you can have a glance at the blog of one of the SO co-developer, which has a "New Developer" section (and BTW is really funny).

Nielk
I think `Drawing the class hierarchies on a sheet of paper` makes sense.
Devil Jin
+2  A: 

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.

mpeterson
+1 Actually using the code is a great way to learn it. There's just no magic pill here.
Mark B
A: 

There are tools which suck up the source code and draw pictures. Try Enterprise Architect from Sparx. It's under $200 per seat and will show you the object layout very effectively.

Bruce
+6  A: 

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?

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, 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. 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.

wallyk
I think this is the best way so far.
Devil Jin
A: 

Hello, First in general I try to answers the question asked before try to say how you have to work. So tools for "reverse engineering" that means code to uml you can check it out from http://case-tools.org/reverse_engineering.html

now if you want to analyse the quality of your UML try: http://sdmetrics.com/FeatOvw.html#FeatOvw is a really nice tool.

If you look for consulting just send me an email.

kind regards mike from http://case-tools.org/uml.html

alud
@alud - thanks, I will give these tools a try. Was actually looking for something like this
Devil Jin
you welcome....
alud