On 5 Jan 2017, at 20:24 , Siemen Baader <siemenbaader@gmail.com> wrote:

Hi All,

I may be missing the obvious, but what are good strategies to understand the structure of existing code? Specifically, I'm trying to understand more of PharoJS to solve my own problems and eventually also to contribute back - but this is a general question.

There is this one MOOC exercise: http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exercises-Pillar/Pillar-Questions.pdf that helps, and reading tests and comments helps if they exist. But I often get trapped in drilling down a long call stack and opening many, many browser windows, a new one for every message send to a new class.

While writing this it occured to me that I can use the debugger to follow a call stack by putting a breakpoint in the top level method, then stepping down using the debugger. There is also a MOOC lecture on that that I will look at again,  http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W5/C019-W2S-VideosDebugger1-UsingTheDebugger-V2-HD_720p_4Mbs.m4v.

Any tips? I think I don't see the forest for the trees here I'm afraid :)

thanks,
Siemen

A break once + debugger is a lifesaver if what you really want is a sequence diagrams of a specific operation; for general structure, the browser is usually a better place to start.

In a well-structured package, the different tags will usually also give a good indication about the class collaboration structure (or, sometimes, lack thereof), or at least the areas that are worth investigating.

Some structural pattern uses are quite easy to spot using the class hierarchy view (at least when not restricted to current package...), such as visitors and polymorphic delegation.
Searching base class references /senders of the polymorphic methods in such cases, will usually progressively take you to classes operating at higher abstraction levels; where the class comment are more likely to describe significant pieces of functionality.
(Some anti-patterns can also be spotted browsing the methods in a polymorphic base class, such as large methods on a super that has overriddes, usually implying copy-pasta-edit, rather than a habit of extracting the bits that actually differ) 

Class collaboration is an area that can be a nuisance to get a good picture of with the standard tools; senders/implementors will usually do the trick when interested in a single area (in a manner similar to the debugger), for a more complete picture, loading Roassal and scripting your own visualizations, or going full throttle and using Moose (which includes a useful set of premade ones, probably/hopefully including scoped collaboration) may be worth the effort.

Cheers,
Henry