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

[damai0419]

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

[across]

敏捷和 uml 冲突么·····

[maichael]

敏捷就不用设计了吗……

[baiyi]

试试领域驱动？
其实我觉得如果是简单的项目，这些方法论意义不大，有这个时间功能都实现了。
还是碰到业务复杂的项目，或后续长期更新维护的项目再用吧。

[damai0419]

@across
@maichael
怪我没说清楚，这里敏捷开发，不指咱们传统意义上的敏捷开发。而是在敏捷外衣下，不经严谨系统设计，就直接开发的那种"敏捷"。

[acthtml]

我举个例子，可能缺少面向对象设计能力，uml 只不过将这些想法以可视化的形式表达出来。

[waytoshine]

没有项目管理人员？出了问题负责人担责就行了

[1490213]

要不要写设计文档，画 UML，是要看复杂度的，野外搭个棚子过夜当然不需要什么设计，但是修个 10 层建筑不画图晚上你敢不敢睡觉？

[jsq2627]

如果只是 CRUD / 前端切图仔，那 UML 确实没啥用（最多画 ER 图）

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

真大佬们抱怨的不是 UML 没用，而是 UML 面对 FP 等一众新概念则显得很不适用

[jsq2627]

而且这年头没几个人会真正按 UML 方法论去画图，大多随便画意思意思就够了

[zjsxwc]

敏捷宣言之一就是 “可运行的软件 胜过 详尽的文档”

[Exin]

> 在敏捷外衣下，不经严谨系统设计，就直接开发的那种"敏捷"。

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

我作为开发有时候不得不自己绘制 UML 图来梳理逻辑。当然 UML 只是梳理逻辑的方式之一，能通过这样的方式让团队对需求的 逻辑 达成清晰的共识就可以。我认为它的价值在于达到了 输出快捷但歧义较多的文本需求 和 输出缓慢但表达精确的程序代码 之间的平衡点，随着场景的不同，我们可以采取或轻量化或严谨化的不同方式。

[lewis89]

其实没有啥好的开发方法论，在最早的人月神话中就已经说的很明白了，软件开发唯一的难题就是软件的复杂性管控，而在这个方面没有银弹，在复杂性管控方面，失控是常态，过去的大瀑布就是流程太长太慢，代码设计不合理与预期不符合，中间可能改需求了，一大堆的情况都可能导致项目中某一阶段的工作需要大量的返工，所以后来大师们才开始推敏捷，按原型做一点然后让用户用起来，根据用户反馈立马改（因为用户一开始本身也不知道他想要什么，我之前做了个一小的外包，前后至少改了 4-5 次需求，每次做一点 让他们用，然后就立马会想出新点子或者瞎几把的玩意），不行推倒一个模块重来，这样可以降低成本失控的风险。

所有开发方面的箴言大多都是有场景的大多都是理想环境，而现实是非常复杂的，项目 人员 编码 设计 等等各个方面就不存在一个理想的情况，反正我上班就是负责在屎堆里面拉屎扒粪，做新模块是最开心的，新项目如果需要改老代码是最难受的，因为每个同事的风格都不一样，有设计的还好，会把一些复杂性隐藏在模块内，把一些接口暴露出来，没有设计的，会把数据库 json 字段序列化反序列化等处理 业务逻辑代码 全部糅合在一起，分散在模块的四处，你一改保证出毛病，最难受的是把缓存跟业务代码糅合在一起，改这种老模块 一旦出 bug 你要排查半天，成本都不一定会比重新写这个模块小。

[lewis89]

如果你觉得缺少方法论，那么就去多思考一下，如何在你的工作中管控复杂性，因为人脑大多时候是没法接受太复杂的事物，即使勉强记下来，也肯定会遗漏，这是人脑性质决定的。

如果将代码模块化管理，隐藏复杂性，例如常见的切面编程技术，本身就是希望代码逻辑是可以快速拔插的，把缓存做在切面层里面就是管控复杂性的方式之一，如果我需要实时看计算的结果，直接关掉缓存是非常简单的，注释掉相关注解，如果你把缓存跟业务代码糅合在一起，就增加了其复杂性，当你需要关掉缓存的时候，你需要在功能模块中大量的注释缓存相关的代码，而且还十分容易出错。

[lewis89]

然后复杂性的另外一个很大的来源就是业务逻辑的多变，像设计模式被总结出来就是用来隔离变化的，可能很多人读设计模式大多只是想生搬硬套，但实际上如果你的代码 预计很长一段时间内不会改变，那么使用设计模式就是脱裤子放屁，因为代码没有变化的源动力存在，去设想未来可能的变化是非常愚蠢的，但是大部分人都知道，变化总是出其意料的出现，也许是业务拍了后脑勺，我要那个，也许是产品又来了个新奇的创意，要设计一违反大多数人直觉的逻辑，反正变化的源动力是没法预测的，所以前辈们的经验就是 不要在同一个地方反复栽跟头，在一个地方改一次 可以 改两次还行，改三次就要考虑是否 扩展成可扩展化的代码结构了。

[Mindjet]

@lewis89 #12 改代码真的是难，前几天刚知道这叫做遗留代码的处理问题，刘未鹏翻译过《修改代码的艺术》这本书，最近在翻阅，刚看了个开头就感觉到很有启发。

[lewis89]

@Mindjet #15 因为大部分代码在一开始设计的时候 就没考虑过变化，如果在这个基础上 再多重复 1-2 次这个代码，你就有的改了，这也是为什么 don't repeat yourself 这么出名的原因，大部分人只会改一处而通常会遗留其它地方。

[lewis89]

@Mindjet #15 我之前也吃过重复自己的坑，遗漏个地方，报错排查了一两个小时。

[Mindjet]

@lewis89 #16 的确如此，学过《重构》或者《代码整洁之道》等关于编码技巧的书，懂得代码是给人看的，就能够明白代码整洁和重构的重要性。

[yangbonis]

虽然没有系统设计，不过那些人又似乎可以控制出现问题的规模。 其实他们并没有进行系统设计，只是 copy 了一个众所周知的系统，然后对它修修改改罢了。只是选择好已知概念的实现，组装在一起罢了。
不写只是因为不值得写。

[laminux29]

UML 的使用，是需要强健的经济来支撑的。

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

其他连发工资和生存都成问题的中小公司，就别来参合 UML 了，洗洗睡了吧。