On Mon, Jul 16, 2012 at 3:58 AM, Ulrich Eckhardt <ulrich.eckha...@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 -- http://mail.python.org/mailman/listinfo/python-list
