These are not meant to distract you from current goals/ways - pick those which ~80% match what you already have, postpone/abandon the others. Like, devOps view is very different from all else, with somewhat weak links across to the product-related or build-related views (heh, new view: costs-related. Be them people-hours or compute/storage). No need to compete with focused tools in that space, (e.g. see [0]). Though some linkage/hints might be doable and valuable. (also see some github-repo visualizers below.)
3+ years ago i landed as architect onto a working system having 300Kloc js codebase across 20+ repos, plus other ~100 unused ones with unknown Mlocs in them, running over 25+ containers in 2 datacenters.. without neither good architectural diagram nor deployment diagram nor runtime flow diagram... took me quite some months to build some mental image of which is what and where and why. It was event-sourcing engine so event-flows mapping from parsing the source was doable (few weeks, python+esprima+graphviz), but all else... nope.
3+ years ago i landed as architect onto a working system having 300Kloc js codebase across 20+ repos, plus other ~100 unused ones with unknown Mlocs in them, running over 25+ containers in 2 datacenters.. without neither good architectural diagram nor deployment diagram nor runtime flow diagram... took me quite some months to build some mental image of which is what and where and why. It was event-sourcing engine so event-flows mapping from parsing the source was doable (few weeks, python+esprima+graphviz), but all else... nope.
Anyway, do ping me if you feel like it, any time.
----
[0] https://news.ycombinator.com/item?id=43161332 - subimage.io
[1] https://news.ycombinator.com/item?id=42521769 - gitdiagram.com
[2] https://news.ycombinator.com/item?id=42976467 (manned service?)
[3] https://news.ycombinator.com/item?id=41393458 - codeviz.ai