Diagramming code

[Joel Goldstick]

On Mon, Jul 16, 2012 at 3:58 AM, Ulrich Eckhardt
<ulrich.eckhardt at dominolaser.com> wrote:
> Am 16.07.2012 03:57, schrieb hamilton:
>
>> OK then, let me ask, how do you guys learn/understand large projects ?
>
>
> 1. Use the program. This gives you an idea what features are there and a bit
> how it could be structured.
> 2. Build the program, to see what is done to get the program running. This
> should give you an idea what pieces there are and where they are [from].
> 3. Read design documentation (which is too often outdated) which should give
> you an idea what the intention of the project's structure is.
> 4. Read the code documentation (which is hopefully more up to date). This
> should give you an idea about responsibilities within the code.
> 5. Read the code itself. This can also be done while single-stepping through
> it with a debugger, just to see it run.
>
> Of course there are also secondary resources like developers' and users'
> mailinglists, websites, bugtrackers that provide information and help.
>
> Sometimes, drawing a few diagrams from steps 3 and 4 to document
> relationships between things is helpful. IMHO having a text describing the
> relationships in prose is superior to that though. In particular a diagram
> can't describe the rationale for something, you need prose for that.
>
> HTH & YMMV
>
> Uli
> --
> http://mail.python.org/mailman/listinfo/python-list

Do you know about pydoc?  Its a great way to get a handle on your
modules.  It doesn't make diagrams, but a synopsis of what is in the
module.  It makes use of docstrings, for the module and each class and
function in the module.

-- 
Joel Goldstick