[图解]需要≠需求-《分析模式》漫谈

1
00:00:00,760 --> 00:00:02,910
今天的《分析模式》漫谈

2
00:00:02,920 --> 00:00:04,180
我们来说一下

3
00:00:04,490 --> 00:00:06,490
需要不等于需求

4
00:00:10,490 --> 00:00:11,760
还是第一章

5
00:00:13,120 --> 00:00:15,020
这里

6
00:00:15,030 --> 00:00:15,740
原文我就不念了

7
00:00:15,750 --> 00:00:17,020
这里有个needs

8
00:00:17,030 --> 00:00:19,980
然后

9
00:00:21,060 --> 00:00:22,060
2004中译本

10
00:00:22,310 --> 00:00:24,710
就是机械工业出版社的译本

11
00:00:25,960 --> 00:00:29,230
翻译“要求”,这是正确的

12
00:00:30,640 --> 00:00:32,280
但是2020中译本

13
00:00:32,490 --> 00:00:37,370
人民邮电出版社的译本,需求

14
00:00:38,290 --> 00:00:39,640
这个就不太对了

15
00:00:40,200 --> 00:00:44,080
需求的话,我们往往会想到什么

16
00:00:44,560 --> 00:00:45,330
Requirements

17
00:00:45,340 --> 00:00:49,940
你看,我们可以看其他地方

18
00:00:49,950 --> 00:00:53,030
你看,这里要求,需求

19
00:00:53,800 --> 00:00:54,810
还是第一章

20
00:00:55,140 --> 00:01:00,640
这里。requirements这里。需求

21
00:01:01,080 --> 00:01:01,390
这个对

22
00:01:01,930 --> 00:01:03,090
你看,这里也是需求

23
00:01:04,970 --> 00:01:08,520
2020中译本needs你也是需求

24
00:01:09,370 --> 00:01:11,090
requirements也是需求

25
00:01:13,210 --> 00:01:14,240
这两个怎么区分

26
00:01:16,890 --> 00:01:17,470
那么我们来看

27
00:01:19,510 --> 00:01:22,380
需求,跟要求或者需要

28
00:01:22,390 --> 00:01:24,620
它不是一个东西

29
00:01:26,150 --> 00:01:31,150
我们可以用这句话来区分

30
00:01:31,710 --> 00:01:35,040
系统的需求,就是requirements 

31
00:01:35,050 --> 00:01:36,440
是平衡各方用户需要

32
00:01:36,450 --> 00:01:39,540
needs的结果

33
00:01:40,740 --> 00:01:44,140
当然用户需要这个说法也不对

34
00:01:44,430 --> 00:01:46,180
更严格应该是涉众利益

35
00:01:46,190 --> 00:01:48,970
因为用户这个词就已经有问题了

36
00:01:49,500 --> 00:01:55,290
我在这个文章,在书里面也有讲

37
00:01:56,520 --> 00:02:00,410
文章公众号上可以看,网址在这里

38
00:02:01,090 --> 00:02:02,900
CTO也糊涂的常用术语

39
00:02:03,310 --> 00:02:04,780
这里就提到用户需求

40
00:02:04,790 --> 00:02:07,010
这个术语是怎么不对的

41
00:02:08,050 --> 00:02:09,450
内容我摘录在这里

42
00:02:12,840 --> 00:02:14,470
需求是系统的需求

43
00:02:15,120 --> 00:02:16,020
它不是你的

44
00:02:16,030 --> 00:02:19,370
我的,谁的,是系统的,就这么一份

45
00:02:19,950 --> 00:02:22,630
它是你我他最终达成的一份

46
00:02:22,640 --> 00:02:24,510
关于系统的一份契约

47
00:02:25,310 --> 00:02:27,290
系统作为一个整体

48
00:02:27,700 --> 00:02:30,890
必须要提供的一些功能性能

49
00:02:32,890 --> 00:02:36,850
用户后面跟什么,可以跟要求或者需要

50
00:02:37,360 --> 00:02:38,310
这个就是needs

51
00:02:39,740 --> 00:02:41,170
不能跟requirements

52
00:02:44,160 --> 00:02:45,700
比如说,拿取款机为例

53
00:02:45,710 --> 00:02:46,830


54
00:02:46,840 --> 00:02:51,610
你储户提出一个要求

55
00:02:51,620 --> 00:02:52,650
说最好拉开就拿

56
00:02:53,490 --> 00:02:54,940
这是大实话

57
00:02:55,960 --> 00:02:57,190
但你不能真的这样做

58
00:02:57,280 --> 00:03:00,900
因为你还要(考虑)别的涉众的利益

59
00:03:01,420 --> 00:03:02,900
就像工厂的工人

60
00:03:02,910 --> 00:03:05,290
你做一个系统给工厂的工人用

61
00:03:05,300 --> 00:03:08,050
你问工人,这个系统该怎么做

62
00:03:08,960 --> 00:03:09,480
你最爽

63
00:03:09,990 --> 00:03:12,100
工人就说,最好操作越简单越好

64
00:03:12,110 --> 00:03:14,240
随便敲两下就搞定

65
00:03:15,170 --> 00:03:16,170
好,你是爽了

66
00:03:16,720 --> 00:03:18,660
但是该采集的数据没采集到

67
00:03:19,560 --> 00:03:21,280
后面的其他同事怎么办

68
00:03:21,600 --> 00:03:22,430
领导怎么办

69
00:03:22,770 --> 00:03:23,110


70
00:03:24,720 --> 00:03:27,900
你说我希望越简单越好

71
00:03:28,330 --> 00:03:29,570
最好敲两下就搞定

72
00:03:31,070 --> 00:03:32,620
这只是你自己的要求

73
00:03:33,190 --> 00:03:35,030
它不能成为系统的需求

74
00:03:36,410 --> 00:03:38,390
最终系统需求要照顾什么

75
00:03:39,430 --> 00:03:40,500
领导的利益

76
00:03:40,830 --> 00:03:41,850
其他同事的利益

77
00:03:42,460 --> 00:03:44,250
当然,在适当的情况下

78
00:03:44,260 --> 00:03:45,770
可以照顾一下你的利益

79
00:03:47,170 --> 00:03:48,850
那就看你的排位了

80
00:03:51,090 --> 00:03:52,860
如果说你这个位置很重要

81
00:03:53,110 --> 00:03:56,320
你提的要求当然是会比较大的程度

82
00:03:56,330 --> 00:03:57,160
得到尊重

83
00:03:57,900 --> 00:03:59,200
如果你是一个屌丝

84
00:04:00,650 --> 00:04:02,770
可能这个系统就要苦一苦你了

85
00:04:03,670 --> 00:04:04,600
就要欺负你了

86
00:04:05,740 --> 00:04:07,420
谁让你排位这么低

87
00:04:08,650 --> 00:04:10,910
这个的话,我们可以看一段

88
00:04:12,160 --> 00:04:14,230
我之前录的教学视频

1
00:00:03,130 --> 00:00:06,800
既然为了方便做卡给我们用

2
00:00:06,810 --> 00:00:07,720
那干嘛不方便到底

3
00:00:07,730 --> 00:00:09,930
为什么要验密码

4
00:00:11,100 --> 00:00:12,060
不验不行吗

5
00:00:13,360 --> 00:00:16,560
储户插卡,系统就弹出一个钱框

6
00:00:17,070 --> 00:00:18,310
储户抓一把就走

7
00:00:19,320 --> 00:00:20,580
这多爽

8
00:00:20,870 --> 00:00:22,380
但是这样就不安全了

9
00:00:24,600 --> 00:00:25,660
所以要验密码

10
00:00:27,480 --> 00:00:28,790
为了安全验密码

11
00:00:28,800 --> 00:00:30,390
密码怎么才6位数字

12
00:00:31,600 --> 00:00:32,400
是不是少了一点

13
00:00:35,540 --> 00:00:36,710
搞个20位密码

14
00:00:37,740 --> 00:00:41,150
或者说数字、大小写字母

15
00:00:41,570 --> 00:00:42,950
特殊符号都要有

16
00:00:43,510 --> 00:00:44,620
那不是更安全吗

17
00:00:45,400 --> 00:00:47,330
但是这样就不方便了

18
00:00:48,040 --> 00:00:52,300
所以6位数字是安全和方便

19
00:00:52,730 --> 00:00:56,510
在当前时间的平衡点,平衡

20
00:00:57,520 --> 00:01:00,650
还有,你看这个,系统验证

21
00:01:00,660 --> 00:01:03,460
金额合法

22
00:01:03,470 --> 00:01:05,540
规则是必须为100元的倍数

23
00:01:06,500 --> 00:01:08,780
¥%……&&,为什么

24
00:01:10,770 --> 00:01:13,540
假设取款机能够取小数点

25
00:01:13,550 --> 00:01:16,890
比如说,我取102块5毛3

26
00:01:18,290 --> 00:01:19,060
然后提交

27
00:01:19,580 --> 00:01:22,710
然后系统就蹦蹦蹦蹦

28
00:01:23,570 --> 00:01:28,470
出钞票,大额的、小额的,硬币都有

29
00:01:29,170 --> 00:01:30,480
那不是更好吗

30
00:01:30,950 --> 00:01:32,320
储户更开心

31
00:01:33,050 --> 00:01:33,980
但是谁不开心

32
00:01:34,920 --> 00:01:36,360
银行这边就不开心了

33
00:01:37,740 --> 00:01:38,840
成本太高了

34
00:01:40,840 --> 00:01:42,840
所以要有这一条

35
00:01:44,910 --> 00:01:49,610
还有这个,为什么要更新账户信息,不更新不行吗

36
00:01:50,910 --> 00:01:52,090
储户喜不喜欢更新

37
00:01:52,950 --> 00:01:56,420
他不喜欢的,比如说,我账户里有2万

38
00:01:57,000 --> 00:01:58,160
我取了5000

39
00:01:59,280 --> 00:02:00,870
我喜不喜欢更新

40
00:02:01,000 --> 00:02:04,440
不更新的,最好还是2万

41
00:02:05,030 --> 00:02:06,100
但是你不更新不行

42
00:02:06,310 --> 00:02:08,140
不更新银行就吃亏了

43
00:02:08,770 --> 00:02:13,080
所以你看这一句,看不见摸不着

44
00:02:14,410 --> 00:02:15,600
储户也不喜欢

45
00:02:16,390 --> 00:02:17,330
但是怎么样

46
00:02:18,730 --> 00:02:20,850
系统必须要写这一句

47
00:02:21,290 --> 00:02:23,170
必须要实现这一句

48
00:02:23,180 --> 00:02:26,130
否则涉众利益就会受到侵害了

49
00:02:27,800 --> 00:02:30,470
每一条背后都有涉众利益的存在

50
00:02:31,440 --> 00:02:32,910
如果没有,就可以把它删掉

  • 13
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Java设计模式是一组经过实践验证的面向对象设计原则和模式,可以帮助开发人员解决常见的软件设计问题。下面是常见的23种设计模式: 1. 创建型模式(Creational Patterns): - 工厂方法模式(Factory Method Pattern) - 抽象工厂模式(Abstract Factory Pattern) - 单例模式(Singleton Pattern) - 原型模式(Prototype Pattern) - 建造者模式(Builder Pattern) 2. 结构型模式(Structural Patterns): - 适配器模式(Adapter Pattern) - 桥接模式(Bridge Pattern) - 组合模式(Composite Pattern) - 装饰器模式(Decorator Pattern) - 外观模式(Facade Pattern) - 享元模式(Flyweight Pattern) - 代理模式(Proxy Pattern) 3. 行为型模式(Behavioral Patterns): - 责任链模式(Chain of Responsibility Pattern) - 命令模式(Command Pattern) - 解释器模式(Interpreter Pattern) - 迭代器模式(Iterator Pattern) - 中介者模式(Mediator Pattern) - 备忘录模式(Memento Pattern) - 观察者模式(Observer Pattern) - 状态模式(State Pattern) - 策略模式(Strategy Pattern) - 模板方法模式(Template Method Pattern) - 访问者模式(Visitor Pattern) 4. 并发型模式(Concurrency Patterns): - 保护性暂停模式(Guarded Suspension Pattern) - 生产者-消费者模式(Producer-Consumer Pattern) - 读写锁模式(Read-Write Lock Pattern) - 信号量模式(Semaphore Pattern) - 线程池模式(Thread Pool Pattern) 这些设计模式可以根据问题的特点和需求来选择使用,它们提供了一些可复用的解决方案,有助于开发高质量、可维护且易于扩展的软件系统。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值