Author | Alex Ellis
Translated by | Hirakawa
Planning | Yan Garden
This article was originally published on Alex Ellis' personal blog.
One day, I was reading about the development of PCs and desktop GUIs, and I thought, we're all pretty used to the analogy of the "desktop" of PCs. We put the files in a folder and put them on the desktop. There are a lot of physical actions that happen in this process.
Humans are very good at understanding space, especially when it comes to memorizing physical space, which reminds me of how we usually visualize code. Is there any good way to take advantage of this when thinking about and visualizing code?
How do I visualize my code?
This got me thinking about how I tend to visualize code, which is a bit hard to describe. I think it usually exists in my mind in different ways, depending on the level of abstraction and particularity, and there are several combinations of different ways at the same time. I can switch between them well if I need to, especially when I'm very familiar with the codebase. For example, when I imagine interactions between various microservices, it's helpful to draw a big box around each service, treating each service as a big unit of work that interacts with each other via RPC.
A simple microservices-oriented car rental service architecture diagram, and distributed tracing representing an execution path.
On the other hand, if I want to know the details of how the computer reads what I give it, then it helps to zoom everything up to a physical memory representation.
I once took a screenshot of a Google Sheets page with a memory address and assembly instructions. This is helpful for a very careful look at the whole process.
Luckily, I spend most of my time somewhere in the middle, making some balance between reading the actual code (higher than assembly), thinking about large chunks of code as big units, and studying architecture diagrams and inter-system communication. Even the code itself already has a lot of physical relationships; think of directory paths, namespaces, line indentation, and linear ordering of lines of code.
How do these visualizations work?
For this question, I considered a number of different visualization techniques, each with a different application scenario. Consider the following incomplete list:
Architecture diagram
Dependency graphs
Distributed tracing
Sequence diagram
Class diagram
Print the statement
Flame diagram
Read the source code
How do you compare them? First, there seems to be a natural hierarchy of abstractions, from low-level code reading to high-level architecture diagrams. There seem to be some other axes that we can sort as well.
Maybe we can rank them based on how much they represent larger systems? Architecture diagrams do a good job of this, but flame diagrams can only represent a single execution path. Maybe it's the frequency of change? This is an interesting problem, and while the source code changes frequently, the architecture diagram (hopefully) remains stable.
Let's think about it, how does visualization represent the actual code execution of the entire system? In this case, the high-level architecture diagram score may not be high because it abstracts away many of the details within the service box. Distributed tracing can do better, but to the extent that it depends on how many trace points there are. While class diagrams help visualize relationships between classes, they may not represent the actual paths. Flame maps can show a clear execution path, but only a single code path, not provide visibility for a larger system.
Drawing on the graph might look like the following, but it might be better to represent the dots above as a range:
It made me think about what the upper right section would look like. What does a useful visualization that gives us insight into detail look like? Is there a way to visualize the path of the entire system at a lower level?
What would it look like if we also used space?
Looking at a map still feels like looking at a map. In that moment, you spatially translate what you see in code into a diagram, just as you would use a map to orient yourself in an unfamiliar place. Like something on a computer, where we use desktop metaphors, I wonder if there's another way to visualize code as something that actually exists in order to make the translation process easier.
What if we used "toy visualization" to represent code in physical space?
Looking at the basic example below, we have a Counter class that has a private count_ variable and provides various access methods. Maybe it will be accessed in a simple main function, doing some counting.
What if we represent different parts of the code as 3D structures? What if we represented the Counter class as a large room with incantations written on the walls? You can imagine the possible paths of code, the connections between variables and the things they represent, like the pink red line in the following diagram:
What can we see in this? First of all, as a private variable, there is obviously nothing wrong with the use of count_, since there is no pink red line leaving the room from it. The public methods are also clear, they have a pink connection to things outside the room.
What's even more interesting is what would it look like if this room was connected to another room? The main function can be another room, and its spell lines are connected accordingly:
Now we can talk across rooms; where the main function calls counter.reset(), we can have a connection from the caller's main to the callee's Counter class. You can even imagine having a debugger step through the process, looking at the parameters and return values on the line. Imagine that we can zoom in on different areas to see the local status and values, and then return to the active region along the call path.
Is this useful?
Is something like this useful? I'm not sure. It's interesting to walk through a familiar codebase in this way, especially if you can do spatial exploration in a 3D representation (or VR environment) and zoom in and out as needed. When exploring a new codebase for the first time, looking at the connections between things, it's not known if it's going to be particularly useful. I did deal with some code bases though, which would be very scary to look at that way. I'd love to see how it makes a difference, every time a new class is introduced, new connections are introduced here and there.
That being said, I think you'll at least run into the following problems when making something like this:
Complex code is difficult to reason about. Visualizing pasta in pasta code is a pleasure, but for very complex code, I don't know how cumbersome it will be?
How do you represent something like threads executing at the same time?
How is it indicated that reference passes instead of value passes?
How do I represent asynchronous work? How is recursion represented? The room keeps nesting?
How to prevent the things inside from becoming obsolete and outdated? At the very least, this needs to be able to be generated automatically.
issue
Several considerations make this problem tricky. One is that changes in physical location usually take much longer than changes in code. Use a familiar physical location as a memory palace, in part because it's the same every time it appears in your memory. If you're memorizing a deck of playing cards, you can temporarily store Plum A behind the cupboard door, and the next time you need to store your playing cards, the cabinet door is still there.
If your codebase changes frequently, maps that reflect the spatial layout of things can change, whether they're 3D generated or purely conscious. It's like going back to a place you used to be familiar with, and imagine that not only have the landmarks changed, but the roads have changed. Even if we are born with the gift of remembering spatial things, if that space changes, if we have to relearn, can we still benefit from spatial visualization?
It's interesting to see how helpful something like this is for exploring a new codebase (like exploring a new city with a map) and getting back to that codebase over time (like going back to your hometown after a long time away).
Code visualization projects
I'm not very familiar with this area of data visualization (nor are other areas), but after a simple search (i.e., a 30-minute Google search), I found that there are several projects that seem to be doing something similar:
SoftVis3D: The Code City view in it provides a visualization of the project hierarchy.
Code Park: A new 3D code visualization tool (2017) that "visualizes the code base in a 3D game-like environment", where the code is represented as a "code room" and the code is on the wall (reading this now, it feels very similar to my idea).
Visualize code structure using 3D-Flythrough (2016), providing spatial metaphors and first-person code exploration.
Primitive: A VR co-op startup with a matrix -- "immersive development environment", including "new tools for 3D visual analysis software".
Here are some of the items that readers point out:
AppMap: An automated code analysis tool that includes dependency graphs and trace views.
plurid: A framework for visualizing and debugging code in a 3D explorable structure.
fsn (File Manager): An experimental application that supports 3D viewing of the file system (appears in Jurassic Park).
If you know about other similar projects, feel free to contact me, I would love to hear more about such projects!
Interesting imagination
Obviously, the concept isn't something groundbreaking, but I think it's an interesting way of thinking about the tools we use, and what matters is how we do it better. There must be a better way to do it, and it would be interesting to imagine what they might look like.
View the original English text:
https://alexanderell.is/posts/visualizing-code/?