I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
First thank you that you as an author of first comment :) and yes your comment is very helpful.
I'm the same opinion as you that UML can help with splitting complex task into smaller. In my opinion it's easier and faster to detect come issues with UML. It'll save developer's time in the future.
I agree that creating and updating documentation in UML is painful. I think that depending on details level we should use UML or unit tests and comments in code as documentation. (By the way I'm a big fan of unit tests). As an example, interactions between two system or system components, architecture of used in system components should be done in UML but implementation details should be documented via a unit tests and comments in code.
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.
First thank you that you as an author of first comment :) and yes your comment is very helpful.
I'm the same opinion as you that UML can help with splitting complex task into smaller. In my opinion it's easier and faster to detect come issues with UML. It'll save developer's time in the future.
I agree that creating and updating documentation in UML is painful. I think that depending on details level we should use UML or unit tests and comments in code as documentation. (By the way I'm a big fan of unit tests). As an example, interactions between two system or system components, architecture of used in system components should be done in UML but implementation details should be documented via a unit tests and comments in code.
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.