这是一个创建于 1559 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题。我刚工作一年(小公司)。在和同学，或者网上和别人交流时，似乎都是 需求--> 原型 --> 开发 --> 修改。
甚至连原型都省了，需求 --> 开发 --> 修改。
没有见过 UML 发挥的作用。
另外: 最近在编码时，感觉缺少一种方法论的指导，我也有点迷，我缺少的是一种什么东西或者能力？
 |
1
across 2020-08-17 11:52:30 +08:00
敏捷和 uml 冲突么·····
|
 |
2
maichael 2020-08-17 11:53:27 +08:00
敏捷就不用设计了吗……
|
 |
3
baiyi 2020-08-17 11:53:43 +08:00
试试领域驱动？
其实我觉得如果是简单的项目，这些方法论意义不大，有这个时间功能都实现了。 还是碰到业务复杂的项目，或后续长期更新维护的项目再用吧。 |
 |
4
damai0419 OP |
 |
5
acthtml 2020-08-17 12:02:09 +08:00
我举个例子，可能缺少面向对象设计能力，uml 只不过将这些想法以可视化的形式表达出来。
|
 |
6
waytoshine 2020-08-17 12:03:40 +08:00 via Android
没有项目管理人员？出了问题负责人担责就行了
|
 |
7
1490213 2020-08-17 12:11:05 +08:00 via Android  3
要不要写设计文档，画 UML，是要看复杂度的，野外搭个棚子过夜当然不需要什么设计，但是修个 10 层建筑不画图晚上你敢不敢睡觉？
|
 |
8
jsq2627 2020-08-17 12:13:12 +08:00
如果只是 CRUD / 前端切图仔，那 UML 确实没啥用（最多画 ER 图）
但凡要做复杂软件的顶层设计，那是很难离开 UML 真大佬们抱怨的不是 UML 没用，而是 UML 面对 FP 等一众新概念则显得很不适用 |
|
9
jsq2627 2020-08-17 12:15:53 +08:00
而且这年头没几个人会真正按 UML 方法论去画图，大多随便画意思意思就够了
|
 |
10
zjsxwc 2020-08-17 12:25:20 +08:00
敏捷宣言之一就是 “可运行的软件 胜过 详尽的文档”
|
 |
11
Exin 2020-08-17 14:33:01 +08:00 1
> 在敏捷外衣下，不经严谨系统设计，就直接开发的那种"敏捷"。
太真实了，而且这种敏捷很多时候不带来效率。 我作为开发有时候不得不自己绘制 UML 图来梳理逻辑。当然 UML 只是梳理逻辑的方式之一，能通过这样的方式让团队对需求的 逻辑 达成清晰的共识就可以。我认为它的价值在于达到了 输出快捷但歧义较多的文本需求 和 输出缓慢但表达精确的程序代码 之间的平衡点，随着场景的不同，我们可以采取或轻量化或严谨化的不同方式。 |
 |
12
lewis89 2020-08-17 14:58:47 +08:00 1
其实没有啥好的开发方法论，在最早的人月神话中就已经说的很明白了，软件开发唯一的难题就是软件的复杂性管控，而在这个方面没有银弹，在复杂性管控方面，失控是常态，过去的大瀑布就是流程太长太慢，代码设计不合理与预期不符合，中间可能改需求了，一大堆的情况都可能导致项目中某一阶段的工作需要大量的返工，所以后来大师们才开始推敏捷，按原型做一点然后让用户用起来，根据用户反馈立马改（因为用户一开始本身也不知道他想要什么，我之前做了个一小的外包，前后至少改了 4-5 次需求，每次做一点 让他们用，然后就立马会想出新点子或者瞎几把的玩意），不行推倒一个模块重来，这样可以降低成本失控的风险。
所有开发方面的箴言大多都是有场景的大多都是理想环境，而现实是非常复杂的，项目 人员 编码 设计 等等各个方面就不存在一个理想的情况，反正我上班就是负责在屎堆里面拉屎扒粪，做新模块是最开心的，新项目如果需要改老代码是最难受的，因为每个同事的风格都不一样，有设计的还好，会把一些复杂性隐藏在模块内，把一些接口暴露出来，没有设计的，会把数据库 json 字段序列化反序列化等处理 业务逻辑代码 全部糅合在一起，分散在模块的四处，你一改保证出毛病，最难受的是把缓存跟业务代码糅合在一起，改这种老模块 一旦出 bug 你要排查半天，成本都不一定会比重新写这个模块小。 |
|
13
lewis89 2020-08-17 15:05:35 +08:00
如果你觉得缺少方法论，那么就去多思考一下，如何在你的工作中管控复杂性，因为人脑大多时候是没法接受太复杂的事物，即使勉强记下来，也肯定会遗漏，这是人脑性质决定的。
如果将代码模块化管理，隐藏复杂性，例如常见的切面编程技术，本身就是希望代码逻辑是可以快速拔插的，把缓存做在切面层里面就是管控复杂性的方式之一，如果我需要实时看计算的结果，直接关掉缓存是非常简单的，注释掉相关注解，如果你把缓存跟业务代码糅合在一起，就增加了其复杂性，当你需要关掉缓存的时候，你需要在功能模块中大量的注释缓存相关的代码，而且还十分容易出错。 |
|
14
lewis89 2020-08-17 15:15:23 +08:00
然后复杂性的另外一个很大的来源就是业务逻辑的多变，像设计模式被总结出来就是用来隔离变化的，可能很多人读设计模式大多只是想生搬硬套，但实际上如果你的代码 预计很长一段时间内不会改变，那么使用设计模式就是脱裤子放屁，因为代码没有变化的源动力存在，去设想未来可能的变化是非常愚蠢的，但是大部分人都知道，变化总是出其意料的出现，也许是业务拍了后脑勺，我要那个，也许是产品又来了个新奇的创意，要设计一违反大多数人直觉的逻辑，反正变化的源动力是没法预测的，所以前辈们的经验就是 不要在同一个地方反复栽跟头，在一个地方改一次 可以 改两次还行，改三次就要考虑是否 扩展成可扩展化的代码结构了。
|
 |
15
Mindjet 2020-08-17 15:39:26 +08:00 1
@lewis89 #12 改代码真的是难，前几天刚知道这叫做遗留代码的处理问题，刘未鹏翻译过《修改代码的艺术》这本书，最近在翻阅，刚看了个开头就感觉到很有启发。
|
|
16
lewis89 2020-08-17 15:41:18 +08:00
@Mindjet #15 因为大部分代码在一开始设计的时候 就没考虑过变化，如果在这个基础上 再多重复 1-2 次这个代码，你就有的改了，这也是为什么 don't repeat yourself 这么出名的原因，大部分人只会改一处而通常会遗留其它地方。
|
|
18
Mindjet 2020-08-17 15:43:12 +08:00
@lewis89 #16 的确如此，学过《重构》或者《代码整洁之道》等关于编码技巧的书，懂得代码是给人看的，就能够明白代码整洁和重构的重要性。
|
 |
19
yangbonis 2020-08-17 15:49:04 +08:00 via iPhone
虽然没有系统设计，不过那些人又似乎可以控制出现问题的规模。 其实他们并没有进行系统设计，只是 copy 了一个众所周知的系统，然后对它修修改改罢了。只是选择好已知概念的实现，组装在一起罢了。
不写只是因为不值得写。 |
 |
20
laminux29 2020-08-17 16:01:51 +08:00
UML 的使用，是需要强健的经济来支撑的。
所以能用 UML 的，也就是国际或国内知名的大型公司了。 其他连发工资和生存都成问题的中小公司，就别来参合 UML 了，洗洗睡了吧。 |
|
22
damai0419 OP |
 |
24
shijingshijing 2020-08-17 16:46:45 +08:00
传统 IT 行业用 UML 的比较多，银行，商业 CRM，工业领域里面，毕竟这些场合都讲究严谨，所以都要梳理清楚，互联网基本上是猛快糙，需求都不一定能写完整写清楚，很多都是开发时候码农自己脑补的。
|
 |
25
zlhsvc 2020-08-17 17:03:59 +08:00
都是螺旋开发
|
 |
26
passerbytiny 2020-08-17 17:45:22 +08:00 via Android
兄弟，你那不是敏捷，且跟敏捷没有任何关系。那是软件工程学最初想要解决的混乱编程。
|
 |
27
liununu 2020-08-17 18:40:22 +08:00
现在项目上虽然没有用 UML 进行设计，但是采取的 DDD 的方式来组织代码，使用 Event Storming 来分析业务。
即使不使用 UML 进行分析，但是也应该采取一些其他手段来梳理流程，并且能够持久化这些设计和决策。 |
|
28
lewis89 2020-08-17 18:46:05 +08:00
@shijingshijing #24 问题是需求方都是老板，大多时候都是拍脑袋，我要这样， 短平快是必然的，按你传统那套来，黄花菜都凉了，估计你还没做完，老板又拍脑袋换方案了
|
 |
29
xuanbg 2020-08-17 18:56:23 +08:00
UML 确实有点过时了……
设计是要做的，但不一定非得用 UML 。我就用 PowerPoint 画架构图，思维导图工具画数据结构图和梳理功能关系，BPMN 设计器画流程图。 |
 |
30
lihongming 2020-08-18 02:58:17 +08:00
20 楼说得对，UML 是要钱的，所以只有特别严谨的大企业（银行之类的）才会用。
对于小公司，尤其是互联网公司，都讲究“快鱼吃慢鱼”，所以快更重要，出错什么的反而不是大问题。 现在流行的微服务架构就很适合这种形式，只要各模块足够独立，就可以各自保证质量。反正我是不相信任何人，内部接口也当黑盒来用，验证数据、handle 错误等一个都不能少。等哪个服务真出错了，再让他去改。 当然这样做的前提是一个服务出错影响不会太大，特别核心的服务，或者如果你身处不允许出错的行业，那还是好好设计一下的好。 |
 |
31
atonku 2020-08-18 08:49:07 +08:00
现在的开发不都这样么，领导脑门一派，吭哧吭哧开发半个月，然后测试一测，改半年
|
 |
32
594duck 2020-08-18 09:43:02 +08:00
我经历的都是敏捷加瀑布的，纯敏捷很容易 就走入了“我想，我觉得，我也不知道，当初怎么搞来着的”
所以敏捷加瀑布才是最好的，至于哪些地方是瀑布哪些地方是敏捷，这个看各公司取舍。 我也见过中华田园敏捷主义，这些公司通常也就半年的命，一年左右的都改成了敏捷加瀑布。 来我们再复习一下“十年前，测试就该死了，怎么现在还有公司有测试，奇怪 ”“有了 Docker 和 K8s，运维死了，今天谁的公司有运维谁就是傻 x” 我们公司一天要销毁 100 个 Docker 实例， 我们是真敏捷。来我给你翻译一下，我们的测试环境一天重启了一百次进程。 |
Select Language