I think that depending on details level we should use UML or unit tests and comments in code as documentation.
Agreed.
I use UML diagrams for top-level documentation, like to show how systems are related to each other. And I find it much more practical to document low-level stuff with the code side by side, in the form of unit tests and code comments, because this way its easier to find the documentation when you need it most and more convenient to update. I do use UML diagrams for low-level stuff on the occasions I need to discuss really complex logic with my colleagues before coding starts.
And for databases, I always design the database on ER diagrams before writing the necessary migration queries, because it is easier to visualise how different DB designs might affect read/write efficiencies.
I think all software professionals should learn to read and write UML diagrams. But when and where they will find it appropriate to use is subjective to the nature of the project (outsourced vs. in-house, waterfall vs. agile, cost of installation / updates) and their team culture. Traditional software delivery business models would favour the use UML diagram more.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Agreed.
I use UML diagrams for top-level documentation, like to show how systems are related to each other. And I find it much more practical to document low-level stuff with the code side by side, in the form of unit tests and code comments, because this way its easier to find the documentation when you need it most and more convenient to update. I do use UML diagrams for low-level stuff on the occasions I need to discuss really complex logic with my colleagues before coding starts.
And for databases, I always design the database on ER diagrams before writing the necessary migration queries, because it is easier to visualise how different DB designs might affect read/write efficiencies.
I think all software professionals should learn to read and write UML diagrams. But when and where they will find it appropriate to use is subjective to the nature of the project (outsourced vs. in-house, waterfall vs. agile, cost of installation / updates) and their team culture. Traditional software delivery business models would favour the use UML diagram more.