191–200 of 239 posts
Well, you need to use an architecture modelling tool to work [efficiently] with architecture models. Here are some I know of: Sparx’s Enterprice Architect NoMagic’s MagicDraw Qualiware Achimate (the tool, not the standard) There are surely more out there. I know both Sparx and MagicDraw have the possibility to write your own custom plugins for the tool. If you are in a big enough shop that will become very handy at s…
Earlier quoted context omitted.
I tend to write up (not necessarily formal UML) diagrams in 2 cases: 1. I'm brainstorming with myself about how I want the software to behave 2. The software is basically done & tested, it's unlikely to change, and communicating the behavior to other people is of value, especially when describing a system that spans multiple components
I'll add (3) When I'm learning a new system, especially if it's big and/or old. The idea is that if I go to the trouble to document it then the next person won't have to; this is seldom the case because as stated above the get out of date so fast. It's still a great way to learn and confirm your understanding though.
Earlier quoted context omitted.
This is pretty common looking for things like CRMs or CMSes where customer specific custom fields rule the day.
The database was meant to be the CMS and SQL was designed to be human readable.
Eg, over a month of iterations: "Can we add another field to user registration? It should be free text. Oh, they should select from a list. No wait, make it a date. Actually a date and a text field. No wait, dump the text field."
Sometimes slowing down these changes is a good thing. But often, being able to ship each iteration along the way will help your design team converge on the best solution. If you need to write a schema migration for every iteration, it kills the ability of your team to experiment and explore the space of "what should our product actually look like".
Faster iterations = more iterations = better product in the long term. Sometimes the best long term result requires some random stuff getting crammed into a big JSON field in your database in the short term.
My workflow right now is hand-drawing diagrams in Paper and pulling them into a Notion page. Notion is amazing, the Paper workflow is not.
Quick question that I only ask because of my 30-odd year history as a corporate contractor... Does anyone here really use those UML-based docs to actually learn the systems? Or do they do what I always did and use the trusty step-debugger for a few days and come up with your own mental model of them? Inevitably, unless someone is working full time on them, they are incomplete and several months out-of-date, and that…
Edit: I'm not too strict on UML exactness, as long as it gives a feel for the components, data flow, etc.
> It then gets saved as PDF and shelved as an artefact that is disconnected from all the other architectures, and the system boundaries are inevitably out of date by the time the next person looks at it.
Personally, I think documentation should be stored into source control like git. Any changes needs to go thru this document first. Specification by Example is one I think would be beneficial. However, all of these takes human willpower and disciple and business buy-in... and is probably why I'm stuck reading an ultra-slow confluence that is not updated.
Quick question that I only ask because of my 30-odd year history as a corporate contractor... Does anyone here really use those UML-based docs to actually learn the systems? Or do they do what I always did and use the trusty step-debugger for a few days and come up with your own mental model of them? Inevitably, unless someone is working full time on them, they are incomplete and several months out-of-date, and that…
I really appreciate having a high-level diagram of system architecture when joining a new project. It gives me an instant feel for whats going on and even if its slightly out of date it gives context to the evolution and design decisions of the codebase since then. That said, there's nothing that beats the good ol' step debugger and diving into the code first hand. They're complementary. Without the diagram its kind…
Earlier quoted context omitted.
They are useful in articulating high-level insight on how systems integrate together. A well done diagram would have an as of date, and some commentary along side boxes.
>> A well done diagram would have an as of date maybe we should promote a "best before" date for technical artifacts...