71–80 of 112 posts
Even a few very basic UML diagrams (Use Cases, Class, Sequence) can form a very effective introduction to a system. I feel that people have just embraced Agile blindly and simply forgot about basic modelling.
Very Good Point!
If you only look at things piecemeal and never holistically, the need for modeling and corresponding tools decreases.
I find those diagrams a lot more confusing than just reading and having a mental model of the code.
It's a very valid criticism of diagram "systems" like UML. But, "read the code" doesn't scale. It makes it brutal when onboarding new team members who will not understand the "tao" of the system without a fireside chat with the original developers. And, usually, the OG devs are long gone...
At the beginning of my career I worked for a company that was started with two reverse-engineering tools: one to produce low-level, single method/function flowcharts and another for automatic extraction of high level components and connections between them. It retired the former and later - the latter and pivoted to static analysis tools: finding logical errors, security vulnerabilities, enforcing coding standards. S…
Honestly, freehand diagrams are best. You’ll exercise your own understanding of the code base as you draw.
I've already mentioned this on the other thread ( https://news.ycombinator.com/item?id=31569646 ), but my friend and I have been working on https://www.codeatlas.dev as a sideproject - it's a tool for creating pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language or other results from static analysis like dead code/test coverage/etc.). Fo…
At the beginning of my career I worked for a company that was started with two reverse-engineering tools: one to produce low-level, single method/function flowcharts and another for automatic extraction of high level components and connections between them. It retired the former and later - the latter and pivoted to static analysis tools: finding logical errors, security vulnerabilities, enforcing coding standards. S…
What were the two tools used?
> Why isn't diagram generation automated as part of the build process (UML or otherwise)? I vaguely recall Visual Studio has this option where you can generate some sort of class diagram. It looked like shit the last time I used it (~2019) especially as your classes get more and more functions built into it. I also can't imagine how shitty it looks for codebases that have a significant coupling problem. Furthermore,…
That's the point, right? Visually representing the complexity of the system. I've used IntelliJ to do this before to show why modifying certain behavior was so slow and error-prone. In that case there were 3-4 classes with heavily overlapping functionality because, surprise, in the past there were multiple teams contributing to the same codebase that all did their own thing.
Also I have rarely seen diagrams generated from code, the main exception being database ERDs ("reverse engineering.") Usually, those diagrams are also a mess.
Also, I almost forgot to mention: with "Agile", there usually is no design process. We'll just "fix it in the next sprint."
It has been used for database schemas, game story creation, cutting up sprites among other things...
Lately I made my own node database so I don't need this tool any longer, but I'm sure it will prove useful eventually again!
In practice it's the same problem as "noodle graph" visual programming. It works well in some niches (e.g. creating shaders in graphics programming, or sometimes describing AI tasks in game programming), but it completely breaks down outside those niches.