"I run this magical tool, and voila! a satellite view of the code!
It clearly shows this river runs into this bay, and there's a dam over there! Now I'm miles ahead of everyone!
Lookie, this river runs in circles..."
Ha.
What really happens is you run some tool and what comes out looks and smells like hair you pulled out of your clogged drain.
I've tried this. Anything graphing shows ... well...
It will look like this:
https://upload.wikimedia.org/wikipedia/commons/9/9b/Social_N...
I think the thing is - the code that gets thing done will confound automated visualization tools.
It's basically like expecting decompiler output to be super helpful. It may help your understanding a little bit, but much will be lost. Yes there are heroic decompiler stories, but time is involved.
Also, most code has macros or helper functions or automatic code generation or something that obfuscates what you're really looking for. You will have to develop a system to unblock this organically.
What will help:
Peruse the source code. Try to follow the flow. if you have tools to jump back and forth between a function call and definition use it.
fix some bugs. Follow the stack traces up and down.
ask people how stuff works. put in the time. and the other stuff mentioned in this article. The osmosis method is really how you'll get it.
The output of a run of profile-guided optimisation could be used to discover that graph, and only the touched functions would be drawn. This graph could be useful to start with the codebase, without being too overwhelming with all the edge cases.
If it's something like a driver or something with a hal or tables of functions or callbacks it might be harder. If your codebase is large... hmm.
Last time I tried something like this was a decade ago so things might have gotten better.
Maybe I should give it another crack for modern languages - there is an even greater need for it these days with dependency injection and microservices being common.
The way I see it the need stems from needing to understand what is REALLY going on, as opposed to what the code is saying should be going on.
https://www.jetbrains.com/help/idea/analyzing-data-flow.html
In addition to Sourcetrail, I also recommend adding OpenTelemetry for distributed projects or flame graphs for less distributed ones. Some of the videos Honeycomb.io put together really highlight the value of distributed tracing, such as this one: https://youtu.be/GuIWQ-EF7YE and the OpenTelemetry Collector makes it simple to filter telemetry, route it to services or drop a majority of traces which don’t have exceptions, for example.
One day I hope OpenTelemetry tracing can be baked into any language the way flame graphs tend to enjoy first-class support in Java, and that tools like Sourcetrail can be baked into IDEs such that runtime metadata is available just by hovering your mouse over modules and functions. Kind of like CodeLens shown here, but for understanding the code: https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp...
Something like https://www.codestream.com/use-cases/code-documentation works as a social network and documentation hub but doesn’t necessarily bring in production telemetry or models/ontology from code (such as Lattix, but that’s specialized to code organization in a way…) Maybe Project Cortex but for source code? https://techcommunity.microsoft.com/t5/microsoft-365-blog/in...
JetBrains Space or GitHub doesn’t yet analyze code beyond dependencies/security issues/CI but might in the future.
Finally, there are tools like https://backstage.io/ which hint at a future where developers build their own infra tools for the rest of the company to use… but that hasn’t extended much into the realm of modelling, documentation or telemetry yet. Folks might be lucky if they have a hosted copy of SourceGraph right now… the future, I think, builds on all of these ideas.
The only other risk is letting your company’s proprietary code be visible by third-parties but Sourcetrail runs locally on your computer and can run completely offline.
As to Sourcetrail’s licensing— it previously had a closed license and was supported by a startup with a number of employees. It recently went open source and can be supported financially through Patreon: https://www.sourcetrail.com/blog/open_source/