关于 UML，画还是不画？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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