墨菲定律对于后端程序员来说真的是条应该写入到生物本能的定律

墨菲定律就是典型的幸存者偏差.. 作为一个程序员应该理性的看待一切 像墨菲定律这种毫无理性的东西就不要到处宣传了

对于一个团队来说应该做的事情是在引入新技术的情况下做好测试和准备工作 并且有预谋的去做好所有可能出现的线上问题
要么就不要引入这个技术

@iosyyy 忘了说了我这里说的是国内普遍认为的墨菲定律 国外版本的"一件事情只要要出错的可能性，就算万分之一，只要继续做下去就一定会出错，如果事情有变坏的可能，不管这种可能性有多小，它总会发生。"与这个还能贴的上边

我的感受是, 埋的坑终究会爆发, 虽然可能是几年后. (我就遇到过, 好几年做的功能用了不太好的实现, 当时我就说这个坑总会造成问题, 最后是三年后确实出问题了

墨菲定律：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。根本内容是：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。

查了一下，这啥玩意。。。说话跟说话一样

啊，你们给出的定义跟我看过的不太一样啊，确切说跟星际穿越里 cooper 说的不一样

85
00:06:05,658 --> 00:06:09,745
Murphy's Law doesn't mean
that something bad will appen.

86
00:06:09,912 --> 00:06:13,291
What it means is
whatever can happen will happen.

考虑边际问题和极端情况这不是程序员正常的思维方式吗

《酒吧点炒饭》
尽可能涵盖所有场景，无法做到全部。

一定要加唯一索引！

找个不会办事的人去给你买个东西跑个腿
你就明白墨菲定律了

墨菲定律：只要有 bug ，就会被发现

@iosyyy 墨菲定律还有一个描述是，如果一件事有很小的出错几率，但只要重复足够的次数，就一定会出错。感觉这个描述很适合后端场景

这个应该是团队能力问题了， 如果团队的能力就只能掌控 10W 行代码， 随着时间推移，需求增加代码涨到 50W 行，超出团队能力掌控范围了，就各种乱了， 除非团队也能随这时间推移能力是提升的，否则就歇菜。

@7zlid 他总能在你意想不到的地方搞砸你的事情
你认为这不是显而易见？
墨菲定律的核心就是
如果有一个地方可以搞砸整个事情，那么肯定有人去搞砸
可能可以理解是熵减比熵增更难

@7zlid 如果有一个地方可以搞砸整个事情，那么肯定有人去搞砸
这件事情在团队工作特别明显，即使是非常厉害的团队也一样
比如 Nasa 的人把卫星砸了…

我挺认同的。

很多时候写一些代码、用一些工具存在侥幸心理，感觉 bug 不会触发、麻烦的事不会到来。但是代码用久了，害怕的事情迟早会出现。

墨菲定律是非常严谨的客观定律，
「在统计样本足够大时，某小概率事件必定发生」
居然还有人说墨菲定律毫无理性...

我觉得，题主说的这个事不是墨菲定律，而是破窗定律；

“随着时间的推移，需求的不断变化，开发人员的变动，用户数带来的放大效应。所有各种以前觉得不太可能写出来的、乱七八糟的、难以置信的错误用法都会被人写出来用到项目中，然后引发灾难性的后果。”引起这个的原因，跟墨菲定律屁都沾不上，这原因推起来非常容易：为什么，因为没有全面测试为什么没有全面测试，因为如果全面测试就要加班为什么要加班才能全面测试，因为全面测试的东西不在计划内为什么全面测试的东西不在计划内，会推向一个国人普片翻的错误：只看结果不看过程。

@iosyyy 我觉得你说的这个做法是我期望的做法。既不因噎废食的敌视新技术，也不盲目冒进的追求新技术。而是采用循序渐进，谨慎的接受新技术。
然后 17 楼的解释是我觉得这个定律要说明的，也是后端需要牢记的。

因为实际情况中，很多后端会主动或被动的忽视它，然后像赌徒一样盲目的引入各种变化，并觉得出问题的可能性不大，或者不会发生在自己身上。

@nothingistrue 测试不是万能的，测试无法覆盖很多临界的情况，也无法覆盖因为测试环境限制而无法测试的部分。并且很多很多时候，测试资源是远远不够的。

这里所说的，其实是后端本身需要约束好自己。因为这块的代价是最小的。

@weiweiwitch #21 不测试你约束个蛋蛋。开发是为需求和测试用例服务的，良好的过程中开发更是只为测试用例服务。自我约束这种没有明确目的的玩意，做了是优点不做是正常，不要把可选的优点变成责任。

很多时候，意外情况在 TODO 和 NOTE 里都写了，甚至还有 FIXME

但是没人改

深有体会，线上好几次 Bug 源于当时的侥幸，只要存在一丝可能就会发生。。