views:

24

answers:

2

(If you think another site on StackExchange or elsewhere is a better location to ask this type of question, please point me in the right direction.)

What do experienced developers use to figure out how the code of an existing application work, before being able to modify/add to it?

Is there a more productive way than going through line by line with pen/paper handy until you figure it out? I find it time-consuming, and difficult to keep the big picture and not get lost with details.

For instance, is there some application that would parse source code and somehow draw a diagram showing the logic in some kind of zoomable storyboard?

Thank you.

A: 

You won't find one tool that addresses all languages and systems. Be specific.

Also, take a look at earlier questions (search for e.g. "tools understand legacy").

Pontus Gagge
+1  A: 

Is there a more productive way than going through line by line with pen/paper handy until you figure it out?

Actually, "pencil & paper" is the best way to understand how the application works. Any tools may fasten up this process, but won't give you any universal answer to your questions - you will still have to analyze the picture, and analyzing takes much more time than just drawing this picture.

If you've got interest in methods, I'm using the following approach:

  1. Find the "top level" points of application (where user requests come in or like that);

  2. Dig down through code to the level you need.

Going through entire code line by line is almost never needed to understand the overall routine of some process in software, just take top-level elements and decompose them until black boxes used in analysis are small enough to understand what you need. Never try to decompose any "black box" you see until you really need smaller details. That's really rarely needed until you start adding and modifying the code. The goal is to know where to find the point to start bugfixing or implementing new features, not to remember every line of code in any component.

Vadim Fedorov