关于 UML，画还是不画？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2598 天前的主题，其中的信息可能已经有所发展或是发生改变。

学校里的老师当然是强调 UML 的重要性啦，从来不说把代码发他，永远都是让我把类图，时序图画出来给他，因为是小项目也没啥难度，画一画也行，没那么费力，我想那些庞大的开源项目会画这些图吗？ Hadoop,Spark 里类何其多啊，调用也多，画 UML 会让人吐血的吧，学术派总说越是大的项目越要 UML 图啊。各位大佬怎么看？

UML

画

hadoop

Spark

22 条回复 • 2017-03-14 11:47:04 +08:00

menc

2017-03-13 16:23:26 +08:00

我们学校的老师早就不让我们画 UML 了， UML 过时了，软件工程课程也是当做老古董讲一讲，都是搞敏捷开发 SCRUM 那一套。
包括小学期的课程实践也是这样。

menc

2017-03-13 16:24:21 +08:00

越大的项目越需要 UML 的话，可以去 github 上统计一下那么多开源的大项目，究竟有多少在 repo 里面放了一个文件夹存 UML 图了，不是一目了然么。

xgfan

2017-03-13 16:39:10 +08:00

可能老师觉得看图比看代码简单多了。

shoaly

2017-03-13 16:56:58 +08:00

结合文档的话, 会画流程图, 越复杂的会越画, 这里的复杂不是项目本身的大小, 而是业务逻辑.
举个例子:
客户下单, 下单之后 ,确认支付, 然后 7 天之后自动评价, 评价的时候, 积分计算, 客户经验值计算. 整个这一条线下来, 还是应该画一下对应设计到的类, 数据表等等, 不然过两天绝壁忘记了.

JunC74

2017-03-13 17:00:28 +08:00

复杂的业务模块不画到后面大家都忘了总体是怎么样的了.

JunC74

2017-03-13 17:03:00 +08:00

画流程图,好找设计问题还有就是重构也有个总体,要不重构一脸黑,还是要自己梳理出 uml 或其它的图来分析.

derek80

2017-03-13 17:05:18 +08:00

@menc UML 和敏捷并不冲突， UML 在今天对业务复杂的系统也是有意义的。

sampeng

2017-03-13 17:51:16 +08:00

初学，需要画。时间是值得的。大项目也是一个一个小模块组合起来的。这是锻炼你的模块化和从下而上思考问题的方法。时间长了就没必要了，因为一个需求出来 uml 就在脑子里了。。

sampeng

2017-03-13 17:55:53 +08:00

我特意花了 500 大洋买了一个 uml 软件。用了两年，然后就很少用了。。确实觉得有些时候如果只是个人开发项目，代码就是 uml 图。有那时间多重构几遍自己的代码。况且有前面的底子在，所以 uml 图不画其实早就在脑子里画了一遍了，不是讲形式主义，实用主义比较好，根据自己的情况进行调整。
最简单和最需要 uml 的例子就是，老大扔给你一个需求需要调研。你输出如果只是代码 demo ， 80 分。如果带 uml 设计，满分逼格送给你。再进行项目交接的时候把图扔过去就能开始讲。我最烦没有设计文档然后交接过来的项目。。。还得翻代码，恶心。

结论就是，一个人，不需要。多人合作。多花的时间，会在将来带来回报。看你是追求眼前利益还是长远利益了

flyingghost

2017-03-13 20:44:20 +08:00

其实画图的目的是为了把事情讲清楚。在这个目标下，形式可以多样化。
现在大部分都以类似敏捷的做法在做项目，所以我最常用的做法是：
框架画模块结构图，模块用文字描述逻辑和实现，关键 /复杂流程画时序图。
UML 里也就只有时序图还在用了。
类图、用例图这些早就不画了。没那闲工夫，而且很难跟得上变化。

loryyang

2017-03-13 20:52:21 +08:00

经典 UML 意义不大，不过可以借鉴一些表达的思路
像 UML 那种画法，能让人累死

aiqier

2017-03-13 20:54:27 +08:00

@menc github 上面的代码都是偏于技术的基础性服务吧，那个当然不需要 uml ，公司开发的大都是业务功能代码，谁会把那个东西往 github 上推，没有 uml ，开发起来很难。

Sharuru

2017-03-13 21:46:01 +08:00

视项目规模而定；
我司的大项目（年级别），从前期技术调查，选型，到概要设计，详细设计，方法说明，开发流程，开发规范，工具使用等各类文档都有记录，都有相关的版本追踪；其中也包括各类业务， DB ， WORKFLOW 的各类图表。

大抵上做起来都是有抗拒的，但是碰到后期要扩展，要理清思路等的场合的情况下，这类资料能起到很大的帮助。

bsidb

2017-03-13 22:09:35 +08:00 via Android

Hadoop 和 Spark 有人专门出书来讲工程的实现代码，这个待遇应该没法比。

Layne

2017-03-14 00:34:24 +08:00

说不要画的应该没接手过那种一句话文档都没有的项目的。。
代码再乱一点，哪哪都不敢动。。

mrcode

2017-03-14 02:00:23 +08:00 via Android

@xgfan 可能老师不想让当年学的东西白学。。。

linux40

2017-03-14 08:22:00 +08:00 via Android

@menc 什么学校啊，羡慕。。。

imlinhanchao

2017-03-14 08:27:42 +08:00

工作之后大家就会明白，一个项目不是你一个人搞得定的。而文档， UML 就是彼此协作的基础。能写出一个让新手也能看懂的文档是十分重要的技能。毕竟图形比文字和代码都要直观得多。

zjsxwc

2017-03-14 08:51:34 +08:00

工作中基本用不到 UML ，因为单元测试代码比看 uml 更高效（通常单元测试代码每次版本更新都会跟着更新，大家都会一起维护，因为要过 QA 那一关，如果是 UML 这类文档的更新就不是及时的了，有时不及时的更新反而会对后来的开发者引起误导，浪费时间），程序员之间即使用 UML 也是大概的用来描述类之间的关系，具体细节全看代码。

shidenggui

2017-03-14 09:10:05 +08:00

以前从来不画，现在开始画了。有助于理清思路

karia

2017-03-14 10:13:13 +08:00

<del>当年老师甚至懒到一笔带过的怎么办....</del>总之从没画过

zthxxx

2017-03-14 11:47:04 +08:00