这是一个创建于 2803 天前的主题，其中的信息可能已经有所发展或是发生改变。
学校里的老师当然是强调 UML 的重要性啦，从来不说把代码发他，永远都是让我把类图，时序图画出来给他，因为是小项目也没啥难度，画一画也行，没那么费力，我想那些庞大的开源项目会画这些图吗？ Hadoop,Spark 里类何其多啊，调用也多，画 UML 会让人吐血的吧，学术派总说越是大的项目越要 UML 图啊。各位大佬怎么看？
 |
1
menc 2017-03-13 16:23:26 +08:00
我们学校的老师早就不让我们画 UML 了， UML 过时了，软件工程课程也是当做老古董讲一讲，都是搞敏捷开发 SCRUM 那一套。
包括小学期的课程实践也是这样。 |
|
2
menc 2017-03-13 16:24:21 +08:00
越大的项目越需要 UML 的话，可以去 github 上统计一下那么多开源的大项目，究竟有多少在 repo 里面放了一个文件夹存 UML 图了，不是一目了然么。
|
 |
3
6IbA2bj5ip3tK49j 2017-03-13 16:39:10 +08:00
可能老师觉得看图比看代码简单多了。
|
 |
4
shoaly 2017-03-13 16:56:58 +08:00
结合文档的话, 会画流程图, 越复杂的会越画, 这里的复杂不是项目本身的大小, 而是业务逻辑.
举个例子: 客户下单, 下单之后 ,确认支付, 然后 7 天之后自动评价, 评价的时候, 积分计算, 客户经验值计算. 整个这一条线下来, 还是应该画一下 对应设计到的类, 数据表等等, 不然过两天绝壁忘记了. |
 |
5
JunC74 2017-03-13 17:00:28 +08:00
复杂的业务模块不画到后面大家都忘了总体是怎么样的了.
|
|
6
JunC74 2017-03-13 17:03:00 +08:00
画流程图,好找设计问题还有就是重构也有个总体,要不重构一脸黑,还是要自己梳理出 uml 或其它的图来分析.
|
 |
8
sampeng 2017-03-13 17:51:16 +08:00
初学，需要画。时间是值得的。大项目也是一个一个小模块组合起来的。这是锻炼你的模块化和从下而上思考问题的方法。时间长了就没必要了，因为一个需求出来 uml 就在脑子里了。。
|
|
9
sampeng 2017-03-13 17:55:53 +08:00  2
我特意花了 500 大洋买了一个 uml 软件。用了两年，然后就很少用了。。确实觉得有些时候如果只是个人开发项目，代码就是 uml 图。有那时间多重构几遍自己的代码。况且有前面的底子在，所以 uml 图不画其实早就在脑子里画了一遍了，不是讲形式主义，实用主义比较好，根据自己的情况进行调整。
最简单和最需要 uml 的例子就是，老大扔给你一个需求需要调研。你输出如果只是代码 demo ， 80 分。如果带 uml 设计，满分逼格送给你。再进行项目交接的时候把图扔过去就能开始讲。我最烦没有设计文档然后交接过来的项目。。。还得翻代码，恶心。 结论就是，一个人，不需要。多人合作。多花的时间，会在将来带来回报。看你是追求眼前利益还是长远利益了 |
 |
10
flyingghost 2017-03-13 20:44:20 +08:00
其实画图的目的是为了把事情讲清楚。在这个目标下，形式可以多样化。
现在大部分都以类似敏捷的做法在做项目，所以我最常用的做法是： 框架画模块结构图，模块用文字描述逻辑和实现，关键 /复杂流程画时序图。 UML 里也就只有时序图还在用了。 类图、用例图这些早就不画了。没那闲工夫，而且很难跟得上变化。 |
 |
11
loryyang 2017-03-13 20:52:21 +08:00
经典 UML 意义不大，不过可以借鉴一些表达的思路
像 UML 那种画法，能让人累死 |
 |
12
aiqier 2017-03-13 20:54:27 +08:00
@menc github 上面的代码都是偏于技术的基础性服务吧，那个当然不需要 uml ，公司开发的大都是业务功能代码，谁会把那个东西往 github 上推，没有 uml ，开发起来很难。
|
 |
13
Sharuru 2017-03-13 21:46:01 +08:00
视项目规模而定；
我司的大项目（年级别），从前期技术调查，选型，到概要设计，详细设计，方法说明，开发流程，开发规范，工具使用等各类文档都有记录，都有相关的版本追踪；其中也包括各类业务， DB ， WORKFLOW 的各类图表。 大抵上做起来都是有抗拒的，但是碰到后期要扩展，要理清思路等的场合的情况下， 这类资料能起到很大的帮助。 |
 |
14
bsidb 2017-03-13 22:09:35 +08:00 via Android
Hadoop 和 Spark 有人专门出书来讲工程的实现代码，这个待遇应该没法比。
|
 |
15
Layne 2017-03-14 00:34:24 +08:00
说不要画的应该没接手过那种一句话文档都没有的项目的。。
代码再乱一点，哪哪都不敢动。。 |
 |
18
imlinhanchao 2017-03-14 08:27:42 +08:00 1
工作之后大家就会明白，一个项目不是你一个人搞得定的。而文档， UML 就是彼此协作的基础。能写出一个让新手也能看懂的文档是十分重要的技能。毕竟图形比文字和代码都要直观得多。
|
 |
19
zjsxwc 2017-03-14 08:51:34 +08:00
工作中基本用不到 UML ，因为单元测试代码比看 uml 更高效（通常单元测试代码每次版本更新都会跟着更新，大家都会一起维护，因为要过 QA 那一关，如果是 UML 这类文档的更新就不是及时的了，有时不及时的更新反而会对后来的开发者引起误导，浪费时间），程序员之间即使用 UML 也是大概的用来描述类之间的关系，具体细节全看代码。
|
 |
20
shidenggui 2017-03-14 09:10:05 +08:00
以前从来不画，现在开始画了。有助于理清思路
|
 |
21
karia 2017-03-14 10:13:13 +08:00
<del>当年老师甚至懒到一笔带过的怎么办....</del>总之从没画过
|
 |
22
zthxxx 2017-03-14 11:47:04 +08:00
平时实际用到的时候，画流程图和框架图多于 UML ，一般是准备好要向被人讲解代码时才画 UML
|
Select Language