Glamorous Toolkit is doing some interesting work here:
Ask HN: Visualizing software designs, especially of large systems (if at all)?
61–70 of 129 posts
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#62Earlier quoted context omitted.
This with Icepanel
This is the most promising tool I've seen in the space. https://icepanel.io/
That's pretty neat. It looks like the support exporting models with JSON, I wonder if they support PlantUML C4 import? Or some sort of import in any case.
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#63I led a project ages ago to divide a massively tangled code base into two parts to facilitate a separation of tech organizations into two (related) companies.
One of the hardest planning parts was “finding the gap” (where was the least unnatural way to place the split). To approach this, I pulled every function’s dependency tree (from code analysis) and all of our relational database entity dependencies (from DBMS telemetry) and all of our functions calling RDBMS code (also code analysis) into a large graph, which I then manipulated with a mix of hand-written tools and Gephi to create logical clusters that were both near-neighbors and business direction aligned (each business was going to have a particular focus, so not all divisions were equivalent).
I don’t recall exactly how long I spent, but it was in the month and a half range to get to a workable initial plan that we could start burning down.
That’s not live tooling to explore a system and is more archeological in nature, but may give you some ideas of how to auto-generate some terrain data.
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#641000% yes it’s a good idea.
As a junior dev, you shouldn’t have to be worried by such things. This should be handled at the senior/principal level.
If you aren’t getting use case diagrams at the very least, you don’t have a clear definition of done.
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#65In my experience, software engineering has ever created 4 types of standardized diagrams that are useful: entity-relationship, data-flow, messages and states-transition. Most share the feature that they communicate data, instead of code.
The standard data-flow diagrams are too low level to be useful nowadays, but it's trivial to remap its symbols into the high-level components our modern distributed systems use. But still, for most people they will just show a database, an application transformation, and the user's output, so they are only useful when you have something different from that to show.
Entity-relationship diagrams were technically included in UML, but the entire world disagrees, so you are better thinking about them as a separated class. Those are in wide use.
Messages diagram (included in UML as sequence diagrams) are very useful to design and analyze protocols, but the UML one is a bad fit for that use due to its serial appearance. If you look at distributed systems papers, you will see a version with oblique arrows instead of horizontal ones that doesn't imply two-sided links, serial communication or even a total order on the messages.
Finally, state machines are a really useful architecture pattern, and states transition diagrams capture them very well.
Every other diagram that I've seen is either completely ad-hock or replacing it with text would improve everything. I really miss some "central architecture diagram" that shows the important structures on your code and how they interact (UML has structure as class diagrams, those suck), but I have never seen any good implementation of this one.
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#66Sequence Diagrams!! They are awesome. You get to see all the entities involved in the architecture and how they interact with each other.
Also https://sequencediagram.org/ allows you to describe them in text and creates a diagram for you.
Its what I have been using.
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#67For what it’s worth: I have good experiences with OPM [0], but not at very large scale.
[0] https://en.m.wikipedia.org/wiki/Object_Process_Methodology
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#68For a small but complicated project I got thrown into a while ago, the only way for me to understand it was to print out all the source directly, vertically tape together the pages for a single file, and then lay them all out on a huge table. Then I took multicolored markers and started physically drawing out the call chains. I then I sers-toi the system, and also found an enraging bug: the system widely used the var…
I use pen and paper as well, but rather than print out all the source code, I write down the call stack. A calls B calls C, etc. along with the line numbers of the call. Much easier than printing out the source and you still have the IDE niceties like go to definition, find in source, etc.
This reminded when I had to maintain dozens of old 10,000 lines COBOL programs as a junior programmer. I felt so lost I made a program that would print only the names of data structures and functions. Seeing the source resumed in a handful of pages, and being able to highlight and draw on it, helped me a lot. Digital has flexibility, but sometimes paper works best.
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#69I've found dataflow analysis to be more helpful than other methods when designing and debugging systems.
However, there are very few automated polyglot methods. So, often, I must trace the data paths manually.
Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?
#70I spent a number of years as a traveling consultant fixing problems... I guess it was aligned with what the cool kids call Site Reliability Engineering these days. Some company would have a crisis and I'd go in and fix it. So basically I had a matter of a few hours to learn as much as I could about some huge system that had probably been built over many years by a whole lot of people.
To do this, I used a number of generally proprietary tools, where part of the project was getting the company to them buy these tools and fix their practices so that perhaps they would avoid the problem in the future.
Anyway, my point is there are open source and proprietary tools out there in the world that will instrument an application and generally based on usage patterns will build out various visualization of the application. While these are often sold or marketed as tools for operational triage, I always argued that the best practice was for developers to use these tools in order to both understand the performance characteristics of their work as well as look for unexpected interactions.
These tools will generally build out a topology of how various components interact and will often do other type of visualizations that will show class and method level chain of invocation. The good ones show end to end across distributed systems every bit of code that gets called from the time a user attempts some kind of action.
The benefit of this approach over a UML diagram or something similar is that it shows how the system was actually built and is working, rather than what a developer intended to be built. The larger the system and the more years / developers involved, the greater the delta.