做个调查:大家在日常工作中会实际用到 UML 吗?

2025 年 3 月 22 日
 shawyeok

什么类图、状态图、部署图 balabala ,反正我司是没见到大家在设计文档中画标准 UML 图的,你们会用吗?

3209 次点击
所在节点    程序员
22 条回复
sunny352787
2025 年 3 月 22 日
我之前会让新来的就当前我们项目中一个模块画个顺序图,算是试用期考察的一部分,考察代码理解能力以及学习知识的能力(大部分人都没听说过顺序图,或者听说过但不知道怎么画,都得现学),不过现在 AI 导致读代码太简单,已经很少这么干了
importmeta
2025 年 3 月 22 日
见过, 功能设计的时候会画一画, 然后讲一讲, 都觉得没问题就继续下一步.
这个也看公司, 没人要求就没人画.
katwalk
2025 年 3 月 22 日
MIT 2022 研究:UML 的非使用价值被忽视,掌握 UML 思维的程序员,即使不画图,其系统分解能力提升 23%
kristofer
2025 年 3 月 22 日
画不画,什么时候画,画的标不标准,取决于能否把需求理解明白,讲明白。没有强制要求必须使用,也无需要求必须标准,目的是让需求清晰,让大家理解顺畅,不本末倒置就可以。

至于说会不会画(指代掌握 UML 的画法),这是计算机/软件的专业课吧,计软专业的人会画是基本素养,如果不会,那只能说上学的时候没好好学了。
linvaux
2025 年 3 月 22 日
会,但是我现在基本用 ai+plantuml 来生成图
nxforce
2025 年 3 月 22 日
在高速迭代的互联网 IT 行业,别说 UML ,毕业出来连 ER 图都没见过几个人人过用。

倒是见过那些非常传统的软件厂商在用,前期文档写得非常啰嗦,有种瀑布流开发感觉,不过这其实和互联网应用关系不是很大,都是做专业路线慢工出细活的产品。
luckyrayyy
2025 年 3 月 22 日
啊?我写技术设计文档基本都是 puml ,主要是用来写清楚时序,系统调用关系。当然用法可能不是非常标准。
securityCoding
2025 年 3 月 23 日
plantuml 有时候用用,纯粹是画图方便
iorilu
2025 年 3 月 23 日
没锤子用

所有东西直接上代码, 包括注释

还不够顶多画几个流程图
shawyeok
2025 年 3 月 23 日
我看现在很多国内软件工程课程里面 UML 还是占用相当一部分比重的。

现在见到最多的还是时序图,特别是 API 涉及到多方交互的,用一个时序图可以很清晰展现交互顺序。例如: https://docs.gitlab.com/ci/runners/long_polling/#long-polling-workflow

利用 Gemini 做了点 research ,贴一下链接: https://docs.google.com/document/d/1e--mLZM38F73IJ6a2DH0U3k8r8nhKI01C2YW3eCgpVQ/edit?usp=sharing
shawyeok
2025 年 3 月 23 日
@iorilu 保持图和代码一致需要大量时间和精力,这一点确实如此。代码结构良好的程序本身就是自说明的。
shawyeok
2025 年 3 月 23 日
@luckyrayyy 实现会变吗?实现变了文档可以确保跟着变么?
raptor
2025 年 3 月 23 日
作为沟通工具还是很有用的
xuanbg
2025 年 3 月 24 日
UML 图太丑了,接受不能。我一般用 BPMN 流程图和思维导图代替 UML
godspeedyou
2025 年 3 月 24 日
个人经常用,对于逻辑和流程复杂的架构还是非常有必要的。而且现在有了 ai ,文字描述下流程可以直接生成 plantuml 或者 mermaid 代码。
johnhuangemc2
2025 年 3 月 24 日
不会系统的使用. 平常在分析问题的时候用一部分. 常用时序图, 通信图.
还有写交互文档的时候会用时序图来说明务系统之前的职责与关系
ashuai
2025 年 3 月 24 日
泳道图用得多,主要为了对齐业务流
newaccount
2025 年 3 月 24 日
一图胜千言,有时候业务复杂度上来之后,文档并不能做到像图片一样,一眼扫过去就明白个大概
而且,状态图对于比文字更能表达清晰逻辑,可以帮助规避不容易发现的 bug

不知道你为什么会觉得这东西没用,但 UML 并不是所谓“八股文”,不同的图有着其不同的适用环境
有些图可能已经不适合现代的软件开发方式,但因为这个就说 UML 无用就如同有人不喜欢吃香菜就骂蔬菜一样

至于觉得业务变了之后图片就没用了,那是你们没有经历过那种整合的开发方式而已
以前用的比较多的 rational rose (这个我们不用,因为跟 IDE 不太搭,我们主用 mmm ),类图跟代码是双向绑定的,你画好类图,代码会自动生成,反之改了代码类图也会自动更新
shawyeok
2025 年 3 月 24 日
@newaccount
不否认 UML 的价值,一图胜前言,图也不一定非得是 UML 图。

图作为重要的沟通工具,比文字会更加直观易懂,这是非常重要的点。有的时候和别人讲解一块业务流,随便一张白纸加一支笔,画的元素主要就是矩形、椭圆和线条,不拘束于标准 UML 那些条条框框。
newaccount
2025 年 3 月 25 日
@shawyeok #19 UML 不是拘泥于形式的条条框框诶

这个的价值是定义了一套规范,大家都遵守的情况下减少沟通成本

如同设计模式,并不是死规定了一套方法来处理问题,而是将大家处理这类问题的最佳实践总结出来给一个特定的名称来代表,这样以后一说名字就知道如何处理

再举个前端例子,prettier 第一句话就是:这是个 opinionated 的格式化工具,大家都认可这种特定词的情况下,仅凭这个 opinionated 就可以决定是否继续使用,后面配置文档看不看都无所谓的,基调已经定下来了

再比如 spring boot 框架,convention over configuration ,这就是它的开发准则,在这个基础上非得按自己意愿乱改配置就是瞎搞

UML 的图并不仅仅是一个图形,它代表了一个词法单元,等同于语言中关键字一样的东西,如果随便乱画,那别人看的时候就得去猜想你在这个图中用这个图例表示什么意思,因为很大几率下一个你所画的图,同样图例表示不同意思,或者用另一个图来表达这个意思,随意性太高大家就没法沟通了
这是没有做过开发的项目经理的做法,不是开发人员应有的素养

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1120339

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX