首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Coding
V2EX  ›  程序员

关于 UML,画还是不画?

  •  1
     
  •   twogoods · 2017-03-13 16:18:40 +08:00 · 4118 次点击
    这是一个创建于 1005 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    22 回复  |  直到 2017-03-14 11:47:04 +08:00
        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
    xgfan   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 或其它的图来分析.
        7
    derek80   2017-03-13 17:05:18 +08:00
    @menc UML 和敏捷并不冲突, 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
    说不要画的应该没接手过那种一句话文档都没有的项目的。。
    代码再乱一点,哪哪都不敢动。。
        16
    mrcode   2017-03-14 02:00:23 +08:00 via Android
    @xgfan 可能老师不想让当年学的东西白学。。。
        17
    linux40   2017-03-14 08:22:00 +08:00 via Android
    @menc 什么学校啊,羡慕。。。
        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
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1048 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 33ms · UTC 23:21 · PVG 07:21 · LAX 15:21 · JFK 18:21
    ♥ Do have faith in what you're doing.