一个技术是否应该用到项目中,不是这个技术好不好用,而是对于团队来说,这个技术中,会引发问题特别是严重问题的风险用法是否都被限制而做到可控了,坑是否被趟完了,后备方案是否做完备了。
这次项目上线真的验证了这条定律!
随着时间的推移,需求的不断变化,开发人员的变动,用户数带来的放大效应。所有各种以前觉得不太可能写出来的、乱七八糟的、难以置信的错误用法都会被人写出来用到项目中,然后引发灾难性的后果。
然后修数据修到抑郁。
1
iosyyy 2022-08-07 14:59:50 +08:00 2
墨菲定律就是典型的幸存者偏差.. 作为一个程序员应该理性的看待一切 像墨菲定律这种毫无理性的东西就不要到处宣传了
|
2
iosyyy 2022-08-07 15:00:54 +08:00
对于一个团队来说应该做的事情是在引入新技术的情况下做好测试和准备工作 并且有预谋的去做好所有可能出现的线上问题
要么就不要引入这个技术 |
3
iosyyy 2022-08-07 15:06:29 +08:00
@iosyyy 忘了说了我这里说的是国内普遍认为的墨菲定律 国外版本的"一件事情只要要出错的可能性,就算万分之一,只要继续做下去就一定会出错,如果事情有变坏的可能,不管这种可能性有多小,它总会发生。"与这个还能贴的上边
|
4
Jooooooooo 2022-08-07 15:13:51 +08:00
我的感受是, 埋的坑终究会爆发, 虽然可能是几年后. (我就遇到过, 好几年做的功能用了不太好的实现, 当时我就说这个坑总会造成问题, 最后是三年后确实出问题了
|
5
zxCoder 2022-08-07 15:26:25 +08:00
墨菲定律:如果有两种或两种以上的方式去做某件事情,而其中一种选择方式将导致灾难,则必定有人会做出这种选择。根本内容是:如果事情有变坏的可能,不管这种可能性有多小,它总会发生。
查了一下,这啥玩意。。。说话跟说话一样 |
6
haoliang 2022-08-07 15:32:07 +08:00 2
啊,你们给出的定义跟我看过的不太一样啊,确切说跟星际穿越里 cooper 说的不一样
85 00:06:05,658 --> 00:06:09,745 Murphy's Law doesn't mean that something bad will happen. 86 00:06:09,912 --> 00:06:13,291 What it means is whatever can happen will happen. |
7
wonderfulcxm 2022-08-07 15:46:01 +08:00 via iPhone
考虑边际问题和极端情况这不是程序员正常的思维方式吗
|
8
wolfie 2022-08-07 17:13:41 +08:00
《酒吧点炒饭》
尽可能涵盖所有场景,无法做到全部。 |
9
LeegoYih 2022-08-07 17:21:44 +08:00
一定要加唯一索引!
|
10
7zlid 2022-08-07 17:37:46 +08:00 via Android
找个不会办事的人去给你买个东西跑个腿
你就明白墨菲定律了 |
11
deesan 2022-08-07 17:56:32 +08:00
墨菲定律:只要有 bug ,就会被发现
|
12
RicardoY 2022-08-07 19:15:27 +08:00 1
@iosyyy 墨菲定律还有一个描述是,如果一件事有很小的出错几率,但只要重复足够的次数,就一定会出错。感觉这个描述很适合后端场景😀
|
13
jones2000 2022-08-07 23:53:42 +08:00
这个应该是团队能力问题了, 如果团队的能力就只能掌控 10W 行代码, 随着时间推移,需求增加代码涨到 50W 行,超出团队能力掌控范围了,就各种乱了, 除非团队也能随这时间推移能力是提升的,否则就歇菜。
|
14
7zlid 2022-08-08 02:19:49 +08:00 via Android
|
15
7zlid 2022-08-08 02:22:20 +08:00 via Android
|
16
aireason 2022-08-08 08:54:15 +08:00
我挺认同的。
很多时候写一些代码、用一些工具存在侥幸心理,感觉 bug 不会触发、麻烦的事不会到来。但是代码用久了,害怕的事情迟早会出现。 |
17
NessajCN 2022-08-08 09:11:54 +08:00 2
墨菲定律是非常严谨的客观定律,
「在统计样本足够大时,某小概率事件必定发生」 居然还有人说墨菲定律毫无理性... |
18
iXInbo 2022-08-08 09:22:35 +08:00
我觉得,题主说的这个事不是墨菲定律,而是破窗定律;
|
19
nothingistrue 2022-08-08 09:34:54 +08:00
“随着时间的推移,需求的不断变化,开发人员的变动,用户数带来的放大效应。所有各种以前觉得不太可能写出来的、乱七八糟的、难以置信的错误用法都会被人写出来用到项目中,然后引发灾难性的后果。”引起这个的原因,跟墨菲定律屁都沾不上,这原因推起来非常容易:为什么,因为没有全面测试——为什么没有全面测试,因为如果全面测试就要加班——为什么要加班才能全面测试,因为全面测试的东西不在计划内——为什么全面测试的东西不在计划内,会推向一个国人普片翻的错误:只看结果不看过程。
|
20
weiweiwitch OP @iosyyy 我觉得你说的这个做法是我期望的做法。既不因噎废食的敌视新技术,也不盲目冒进的追求新技术。而是采用循序渐进,谨慎的接受新技术。
然后 17 楼的解释是我觉得这个定律要说明的,也是后端需要牢记的。 因为实际情况中,很多后端会主动或被动的忽视它,然后像赌徒一样盲目的引入各种变化,并觉得出问题的可能性不大,或者不会发生在自己身上。 |
21
weiweiwitch OP @nothingistrue 测试不是万能的,测试无法覆盖很多临界的情况,也无法覆盖因为测试环境限制而无法测试的部分。并且很多很多时候,测试资源是远远不够的。
这里所说的,其实是后端本身需要约束好自己。因为这块的代价是最小的。 |
22
nothingistrue 2022-08-08 12:46:40 +08:00
@weiweiwitch #21 不测试你约束个蛋蛋。开发是为需求和测试用例服务的,良好的过程中开发更是只为测试用例服务。自我约束这种没有明确目的的玩意,做了是优点不做是正常,不要把可选的优点变成责任。
|
23
tairan2006 2022-08-08 13:41:41 +08:00
很多时候,意外情况在 TODO 和 NOTE 里都写了,甚至还有 FIXME
但是没人改 |
24
alen0206 2022-08-08 14:00:56 +08:00
深有体会,线上好几次 Bug 源于当时的侥幸,只要存在一丝可能就会发生。。
|