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

敏捷开发大行其道, UML 在实际工作还有多少程度的使用?

  •  
  •   damai0419 · 2020-08-17 11:48:01 +08:00 · 4042 次点击
    这是一个创建于 1320 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题。我刚工作一年(小公司)。在和同学,或者网上和别人交流时,似乎都是 需求--> 原型 --> 开发 --> 修改。
    甚至连原型都省了,需求 --> 开发 --> 修改。
    没有见过 UML 发挥的作用。
    另外: 最近在编码时,感觉缺少一种方法论的指导,我也有点迷,我缺少的是一种什么东西或者能力?

    across
        1
    across  
       2020-08-17 11:52:30 +08:00
    敏捷和 uml 冲突么·····
    maichael
        2
    maichael  
       2020-08-17 11:53:27 +08:00
    敏捷就不用设计了吗……
    baiyi
        3
    baiyi  
       2020-08-17 11:53:43 +08:00
    试试领域驱动?
    其实我觉得如果是简单的项目,这些方法论意义不大,有这个时间功能都实现了。
    还是碰到业务复杂的项目,或后续长期更新维护的项目再用吧。
    damai0419
        4
    damai0419  
    OP
       2020-08-17 12:00:52 +08:00
    @across
    @maichael
    怪我没说清楚,这里敏捷开发,不指咱们传统意义上的敏捷开发。而是在敏捷外衣下,不经严谨系统设计,就直接开发的那种"敏捷"。
    acthtml
        5
    acthtml  
       2020-08-17 12:02:09 +08:00
    我举个例子,可能缺少面向对象设计能力,uml 只不过将这些想法以可视化的形式表达出来。
    waytoshine
        6
    waytoshine  
       2020-08-17 12:03:40 +08:00 via Android
    没有项目管理人员?出了问题负责人担责就行了
    1490213
        7
    1490213  
       2020-08-17 12:11:05 +08:00 via Android   ❤️ 3
    要不要写设计文档,画 UML,是要看复杂度的,野外搭个棚子过夜当然不需要什么设计,但是修个 10 层建筑不画图晚上你敢不敢睡觉?
    jsq2627
        8
    jsq2627  
       2020-08-17 12:13:12 +08:00
    如果只是 CRUD / 前端切图仔,那 UML 确实没啥用(最多画 ER 图)

    但凡要做复杂软件的顶层设计,那是很难离开 UML

    真大佬们抱怨的不是 UML 没用,而是 UML 面对 FP 等一众新概念则显得很不适用
    jsq2627
        9
    jsq2627  
       2020-08-17 12:15:53 +08:00
    而且这年头没几个人会真正按 UML 方法论去画图,大多随便画意思意思就够了
    zjsxwc
        10
    zjsxwc  
       2020-08-17 12:25:20 +08:00
    敏捷宣言之一就是 “可运行的软件 胜过 详尽的文档”
    Exin
        11
    Exin  
       2020-08-17 14:33:01 +08:00   ❤️ 1
    > 在敏捷外衣下,不经严谨系统设计,就直接开发的那种"敏捷"。

    太真实了,而且这种敏捷很多时候不带来效率。

    我作为开发有时候不得不自己绘制 UML 图来梳理逻辑。当然 UML 只是梳理逻辑的方式之一,能通过这样的方式让团队对需求的 逻辑 达成清晰的共识就可以。我认为它的价值在于达到了 输出快捷但歧义较多的文本需求 和 输出缓慢但表达精确的程序代码 之间的平衡点,随着场景的不同,我们可以采取或轻量化或严谨化的不同方式。
    lewis89
        12
    lewis89  
       2020-08-17 14:58:47 +08:00   ❤️ 1
    其实没有啥好的开发方法论,在最早的人月神话中就已经说的很明白了,软件开发唯一的难题就是软件的复杂性管控,而在这个方面没有银弹,在复杂性管控方面,失控是常态,过去的大瀑布就是流程太长太慢,代码设计不合理与预期不符合,中间可能改需求了,一大堆的情况都可能导致项目中某一阶段的工作需要大量的返工,所以后来大师们才开始推敏捷,按原型做一点然后让用户用起来,根据用户反馈立马改(因为用户一开始本身也不知道他想要什么,我之前做了个一小的外包,前后至少改了 4-5 次需求,每次做一点 让他们用,然后就立马会想出新点子或者瞎几把的玩意),不行推倒一个模块重来,这样可以降低成本失控的风险。

    所有开发方面的箴言大多都是有场景的大多都是理想环境,而现实是非常复杂的,项目 人员 编码 设计 等等各个方面就不存在一个理想的情况,反正我上班就是负责在屎堆里面拉屎扒粪,做新模块是最开心的,新项目如果需要改老代码是最难受的,因为每个同事的风格都不一样,有设计的还好,会把一些复杂性隐藏在模块内,把一些接口暴露出来,没有设计的,会把数据库 json 字段序列化反序列化等处理 业务逻辑代码 全部糅合在一起,分散在模块的四处,你一改保证出毛病,最难受的是把缓存跟业务代码糅合在一起,改这种老模块 一旦出 bug 你要排查半天,成本都不一定会比重新写这个模块小。
    lewis89
        13
    lewis89  
       2020-08-17 15:05:35 +08:00
    如果你觉得缺少方法论,那么就去多思考一下,如何在你的工作中管控复杂性,因为人脑大多时候是没法接受太复杂的事物,即使勉强记下来,也肯定会遗漏,这是人脑性质决定的。

    如果将代码模块化管理,隐藏复杂性,例如常见的切面编程技术,本身就是希望代码逻辑是可以快速拔插的,把缓存做在切面层里面就是管控复杂性的方式之一,如果我需要实时看计算的结果,直接关掉缓存是非常简单的,注释掉相关注解,如果你把缓存跟业务代码糅合在一起,就增加了其复杂性,当你需要关掉缓存的时候,你需要在功能模块中大量的注释缓存相关的代码,而且还十分容易出错。
    lewis89
        14
    lewis89  
       2020-08-17 15:15:23 +08:00
    然后复杂性的另外一个很大的来源就是业务逻辑的多变,像设计模式被总结出来就是用来隔离变化的,可能很多人读设计模式大多只是想生搬硬套,但实际上如果你的代码 预计很长一段时间内不会改变,那么使用设计模式就是脱裤子放屁,因为代码没有变化的源动力存在,去设想未来可能的变化是非常愚蠢的,但是大部分人都知道,变化总是出其意料的出现,也许是业务拍了后脑勺,我要那个,也许是产品又来了个新奇的创意,要设计一违反大多数人直觉的逻辑,反正变化的源动力是没法预测的,所以前辈们的经验就是 不要在同一个地方反复栽跟头,在一个地方改一次 可以 改两次还行,改三次就要考虑是否 扩展成可扩展化的代码结构了。
    Mindjet
        15
    Mindjet  
       2020-08-17 15:39:26 +08:00   ❤️ 1
    @lewis89 #12 改代码真的是难,前几天刚知道这叫做遗留代码的处理问题,刘未鹏翻译过《修改代码的艺术》这本书,最近在翻阅,刚看了个开头就感觉到很有启发。
    lewis89
        16
    lewis89  
       2020-08-17 15:41:18 +08:00
    @Mindjet #15 因为大部分代码在一开始设计的时候 就没考虑过变化,如果在这个基础上 再多重复 1-2 次这个代码,你就有的改了,这也是为什么 don't repeat yourself 这么出名的原因,大部分人只会改一处而通常会遗留其它地方。
    lewis89
        17
    lewis89  
       2020-08-17 15:42:14 +08:00
    @Mindjet #15 我之前也吃过重复自己的坑,遗漏个地方,报错排查了一两个小时。
    Mindjet
        18
    Mindjet  
       2020-08-17 15:43:12 +08:00
    @lewis89 #16 的确如此,学过《重构》或者《代码整洁之道》等关于编码技巧的书,懂得代码是给人看的,就能够明白代码整洁和重构的重要性。
    yangbonis
        19
    yangbonis  
       2020-08-17 15:49:04 +08:00 via iPhone
    虽然没有系统设计,不过那些人又似乎可以控制出现问题的规模。 其实他们并没有进行系统设计,只是 copy 了一个众所周知的系统,然后对它修修改改罢了。只是选择好已知概念的实现,组装在一起罢了。
    不写只是因为不值得写。
    laminux29
        20
    laminux29  
       2020-08-17 16:01:51 +08:00
    UML 的使用,是需要强健的经济来支撑的。

    所以能用 UML 的,也就是国际或国内知名的大型公司了。

    其他连发工资和生存都成问题的中小公司,就别来参合 UML 了,洗洗睡了吧。
    damai0419
        21
    damai0419  
    OP
       2020-08-17 16:22:25 +08:00
    @jsq2627 感谢解惑。
    damai0419
        22
    damai0419  
    OP
       2020-08-17 16:23:28 +08:00
    @Exin
    > 价值在于达到了 输出快捷但歧义较多的文本需求 和 输出缓慢但表达精确的程序代码 之间的平衡点。
    感谢回答,赞同这个观点。
    damai0419
        23
    damai0419  
    OP
       2020-08-17 16:26:24 +08:00
    @lewis89 感谢解惑。我还是太嫩了,还需要多编码多思考多见识,才能切身体会到。感谢。
    shijingshijing
        24
    shijingshijing  
       2020-08-17 16:46:45 +08:00
    传统 IT 行业用 UML 的比较多,银行,商业 CRM,工业领域里面,毕竟这些场合都讲究严谨,所以都要梳理清楚,互联网基本上是猛快糙,需求都不一定能写完整写清楚,很多都是开发时候码农自己脑补的。
    zlhsvc
        25
    zlhsvc  
       2020-08-17 17:03:59 +08:00
    都是螺旋开发
    passerbytiny
        26
    passerbytiny  
       2020-08-17 17:45:22 +08:00 via Android
    兄弟,你那不是敏捷,且跟敏捷没有任何关系。那是软件工程学最初想要解决的混乱编程。
    liununu
        27
    liununu  
       2020-08-17 18:40:22 +08:00
    现在项目上虽然没有用 UML 进行设计,但是采取的 DDD 的方式来组织代码,使用 Event Storming 来分析业务。
    即使不使用 UML 进行分析,但是也应该采取一些其他手段来梳理流程,并且能够持久化这些设计和决策。
    lewis89
        28
    lewis89  
       2020-08-17 18:46:05 +08:00
    @shijingshijing #24 问题是需求方都是老板,大多时候都是拍脑袋,我要这样, 短平快是必然的,按你传统那套来,黄花菜都凉了,估计你还没做完,老板又拍脑袋换方案了
    xuanbg
        29
    xuanbg  
       2020-08-17 18:56:23 +08:00
    UML 确实有点过时了……

    设计是要做的,但不一定非得用 UML 。我就用 PowerPoint 画架构图,思维导图工具画数据结构图和梳理功能关系,BPMN 设计器画流程图。
    lihongming
        30
    lihongming  
       2020-08-18 02:58:17 +08:00
    20 楼说得对,UML 是要钱的,所以只有特别严谨的大企业(银行之类的)才会用。

    对于小公司,尤其是互联网公司,都讲究“快鱼吃慢鱼”,所以快更重要,出错什么的反而不是大问题。

    现在流行的微服务架构就很适合这种形式,只要各模块足够独立,就可以各自保证质量。反正我是不相信任何人,内部接口也当黑盒来用,验证数据、handle 错误等一个都不能少。等哪个服务真出错了,再让他去改。

    当然这样做的前提是一个服务出错影响不会太大,特别核心的服务,或者如果你身处不允许出错的行业,那还是好好设计一下的好。
    atonku
        31
    atonku  
       2020-08-18 08:49:07 +08:00
    现在的开发不都这样么,领导脑门一派,吭哧吭哧开发半个月,然后测试一测,改半年
    594duck
        32
    594duck  
       2020-08-18 09:43:02 +08:00
    我经历的都是敏捷加瀑布的,纯敏捷很容易 就走入了“我想,我觉得,我也不知道,当初怎么搞来着的”

    所以敏捷加瀑布才是最好的,至于哪些地方是瀑布哪些地方是敏捷,这个看各公司取舍。

    我也见过中华田园敏捷主义,这些公司通常也就半年的命,一年左右的都改成了敏捷加瀑布。

    来我们再复习一下“十年前,测试就该死了,怎么现在还有公司有测试,奇怪 ”“有了 Docker 和 K8s,运维死了,今天谁的公司有运维谁就是傻 x”

    我们公司一天要销毁 100 个 Docker 实例, 我们是真敏捷。来我给你翻译一下,我们的测试环境一天重启了一百次进程。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5332 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 08:10 · PVG 16:10 · LAX 01:10 · JFK 04:10
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.