4 ms·
I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases. I was eager to use
by doctor_eval 3y ago
I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases.
I was eager to use UML when it came out but I agree with the article, the only thing I kept was sequence diagrams. Most of the rest of it was just a complicated way to represent stuff that is best represented in code or plain documentation.
I’m also not afraid to use stuff that’s out of fashion. I use simplified ER diagrams, and even flow charts on occasion.
But the tool I use most often in design is SQL DDL…
I have also used Mermaid (using a modified Docsy theme in Hugo) and it is also great. Using Typora to edit Mermaid is also excellent.
- ozim 3y agoI like use case diagrams as well. Thing is these should be short lived and used to make specific illustration in specific time. Not some holy grail of documentation that people should take as some god given truth for whole life of the system.
- doctor_eval 3y agoYeah, I posted elsewhere in this thread that I'm a big fan of Jack Reeves' essays on "code as design"; namely, that the code is what's important, and the design is just scaffolding. "The following essays by Jack W. Reeves offer three perspectives on a single theme, namely that programming is fundamentally a design activity and that the only final and true representation of "the design" is the source code itself. This simple assertion gives rise to a rich discussion—one which Reeves explores fully in these three essays." https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_...
- macdaknife 3y agoYes, actors and actions. It's the crux of the use case. I'm still operating under the assumption that UML invented the modern use case. I will not be googling this next.