Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >系统设计得应该没问题吧——墨菲定律

系统设计得应该没问题吧——墨菲定律

作者头像
普通程序员
发布于 2019-10-23 06:12:06
发布于 2019-10-23 06:12:06
5980
举报
文章被收录于专栏:普通程序员普通程序员

“系统设计得应该没问题吧”,当你内心在这么问自己的时候,那么这个系统肯定存在非常多的问题!

Anything that can go wrong will go wrong!

一、什么是墨菲定律

墨菲是美国爱德华兹空军基地的上尉工程师。1949年,他和他的上司斯塔普少校,在一次火箭减速超重试验中(human tolerance for g-forces during rapid deceleration),因仪器失灵发生了事故。墨菲发现,测量仪表被一个技术人员装反了。由此,他得出的教训是:如果做某项工作有多种方法,而其中有一种方法将导致事故,那么一定有人会按这种方法去做。

一句本无恶意的玩笑话最初并没有什么太深的含义,只是说出了坏运气带给人的无奈。或许是这世界不走运的人太多,或许是人们总会犯这样那样错误的缘故,这句话被迅速扩散,最后竟然演绎成:如果坏事情有可能发生,不管这种可能性有多小,它总会发生,并引起最大可能的损失。

二、理论依据

在数理统计中,有一条重要的统计规律:假设某意外事件在一次实验(活动)中发生的概率为p(p>0),则在n次实验(活动)中至少有一次发生的概率为pn=1-(1-p)n。由此可见,无论概率p多么小(即小概率事件),当n越来越大时,pn越来越接近1。

这一结论被爱德华·墨菲应用于安全管理,他指出:做任何一件事情,如果客观上存在着一种错误的做法,或者存在着发生某种事故的可能性,不管发生的可能性有多小,当重复去做这件事时,事故总会在某一时刻发生。也就是说,只要发生事故的可能性存在,不管可能性多么小,这个事故迟早会发生的。

三、具体定律

墨菲定律(Murphy's Law)主要内容有四个方面

1、任何事都没有表面看起来那么简单

设计系统时,多问问自己是不是考虑全面了,多请教这方面的资深人士。如果有可能,借鉴已有被验证的成熟方案。在继承的基础上创新风险相对小一些。

2、所有的事都会比你预计的时间长

很多项目是倒排时间的,前紧后松会让项目出问题的概率降低。一定要不断向团队强调时间意识,经验不够丰富的成员估计的时间肯定不够!我在按周迭代的项目中,会尽可能要求成员只用一半的时间做开发,后边留给测试和上线的工作。最重要的是让所有成员一开始就充分工作起来。只要大方向没错,先执行起来!

3、会出错的事总会出错

我经常给组内同学说,一定要搞定一件事。

有些同学把明面上那点工作完成后就等着了,等着别人集成,等着来联调,等着QA测试。这样不太好,你可以多写点单测,让自己负责模块更健壮;了解你这块在整个系统中的定位,跟前后左右的系统的关系,甚至推着相关方向前跑。

系统不少问题都出现在模块间的调用上。做好你这块,同时保证跟前后左右的系统间的依赖都OK才算搞定一件事。

4、如果你担心某种情况发生,那么它就更有可能发生

文章开头那句话,“系统设计得应该没问题吧”。如果你做的东西,自己心里都没底,那大概率是有问题的。

“墨菲定律”的根本内容是“凡是可能出错的事有很大几率会出错”,指的是任何一个事件,只要具有大于零的机率,就不能够假设它不会发生。

四、扩展

墨菲定律应用于不同行业或领域,衍生出了不少有意思的“定律”,可以在http://www.murphys-laws.com/进行查看,网站首页如下图

看的大多是程序员,Murphy’s love laws送给大家

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-04-07,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 普通程序员 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
墨菲定律是运维的魔咒!
什么是墨菲定律?最简单的表达形式是“有可能出错的事情,就会出错(Anything that can go wrong will go wrong)。”爱德华·墨菲(Edward A. Murphy)是一名工程师,这句话迅速流传。墨菲定律的原句是这样的:If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it.(如果有两种选择,其中一种将导致灾难,则必定有人会作出这种选择。)
用户1593318
2019/11/18
8360
由手抖想到的
本文所谓的手抖是指一个小的操作导致较大事故的事件,每个人应该都有属于自己的手抖时刻,只是我们更愿意将它们放在心底,仅供自己把玩。
wangning
2022/06/13
2170
每个程序员都该知道的五大定律
定律 - 或称法则,可以指导我们并让我们在同伴的错误中学习。这篇文章中,我将介绍我每次设计或实现软件时出现在我脑海的五大定律。其中有些和开发有关,有些和系统组织有关。它们可以帮助你成为合格的软件工程师。 墨菲定律 “ “凡事可能出错,就一定出错” ” “墨菲定律” 是一种心理学效应,是由爱德华 · 墨菲(Edward A. Murphy)提出的。他的主要内容是:(1)任何事都没有表面看起来那么简单;(2)所有的事都会比你预计的时间长;(3)会出错的事总会出错;(4)如果你担心某种情况发生,那么它就更有可能发
企鹅号小编
2018/02/06
1.3K0
每个程序员都该知道的五大定律
《微服务设计》第 10 章 康威定律和系统设计
第 10 章 康威定律和系统设计 梅尔 · 康威于 1968 年 4 月 在 Datamation 杂志上发表了一篇名为“How Do Committees Invent”的论文,文中指出:任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。这句话被称为康威定律 ---- 10.1 证据 ---- 10.1.1 松耦合组织和紧耦合组织 在 Exploring the Duality Between Product and Organizational Arch
yeedomliu
2019/09/30
4940
《微服务设计》第 10 章 康威定律和系统设计
享知行·思考:不要再拜服务器啦,墨菲定律有空了解一下
虔诚的膜拜机房真的有用吗?贴上一张“永不宕机”的神符,服务器真的就不会宕机吗?该宕机还是会宕机,只是概率大小的问题罢了。“得道高僧”就能永保平安?与其如此,不如学习一下墨菲定律。
用户4361942
2019/05/24
5770
生活中常见的一些名词解释
  强弱危机分析(英语:SWOT Analysis),又称优劣分析法、SWOT分析法或道斯矩阵,是一种企业竞争态势分析方法,是市场营销的基础分析方法之一,透过评价自身的优势(Strengths)、劣势(Weaknesses)、外部竞争上的机会(Opportunities)和威胁(Threats),用以在制定发展战略前对自身进行深入全面的分析以及竞争优势的定位。而此方法是Albert Humphrey所提。   SWOT分析在最理想的状态下,是由专属的团队来达成的,一个SWOT分析团队,最好由一个会计相关人员,一位销售人员,一位经理级主管,一位工程师和一位项目管理师的组成。
老猫-Leo
2023/12/11
1860
程序员应该熟悉的定律法则
本文由腾讯云+社区自动同步,原文地址 http://stackoverflow.club/article/programmer_should_know_laws/
羽翰尘
2019/11/21
4780
读书笔记:交易型系统设计的一些原则
一个好的设计要做到,解决现有的需求和问题,把控实现和进度风险,预测和规划未来,不要过度设计,从迭代中演进和完善。
看、未来
2021/12/05
3040
读书笔记:交易型系统设计的一些原则
每个程序员都该知道的 5 个定律
本文探讨了软件工程师和团队在开发过程中遵循的5个定律。首先介绍了墨菲定律,它强调错误和意外总会发生。其次介绍了Knuth定律,它提醒我们不要过早优化代码。然后是垃圾回收的编程语言中的字符串连接问题,以及Conway定律,强调组织沟通方式对系统设计的影响。最后是帕金森琐碎定律,指出人们倾向于将注意力放在熟悉的事物上,而不是复杂问题上。
企鹅号小编
2018/01/04
5640
每个程序员都该知道的 5 个定律
程序员N定律和N原则---康威定律在实践中的一点思考
以前我们或多或少都听说过一些定律,比如木桶定律、墨菲定律、摩尔定律、鲇鱼效应、多米诺骨牌效应、马太效应等等等等。在软件工程领域中,也有适用软件开发和组织管理的经典定律和原则,这些经典的定律和原则被程序员上传到了代码托管平台Github 上,并且被翻译成了多国语言版本,中文版可见https://github.com/nusr/hacker-laws-zh。这里罗列一下:
别打名名
2020/05/09
1.4K0
程序员N定律和N原则---康威定律在实践中的一点思考
每名开发人员都会遇到的 8 条编程法则
作者|Adam Hughes 译者|平川 策划|marsxxl 本文最初发布于 Level Up Coding。 多年来,我观察到了一些在工程过程中反复出现的基本模式和陷阱。有趣的是,它们与工程博客上无休止争论的话题无关。例如,我不记得哪一次我的团队因为对 SOLID 原则理解不足而导致错过了交付期限。偶尔,我会遇到一条“法则”,它完美描述了我所经历的问题。令人恼火的是,这些便利的工程定律却往往在播客、有声读物和博客的边角隐蔽处。所以我把它们整理成一个清单,其中列出了我最喜欢的 8 条编程法则,你肯定也会在
深度学习与Python
2023/03/29
3860
每名开发人员都会遇到的 8 条编程法则
线上服务应急攻关方法论
每一起严重事故的背后,必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。
用户1516716
2020/06/17
6390
线上服务应急攻关方法论
Github标星1.6W+,程序员不得不知的“潜规则”又火了,早知道就不会秃头了
这条原则也被收藏,还有一些不太常见的费茨法则、盖尔定律、康威定律等,都被一一收入囊中。
夜尽天明
2023/03/15
4120
Github标星1.6W+,程序员不得不知的“潜规则”又火了,早知道就不会秃头了
电商前端交易型系统设计原则
个人认为设计系统要因场景因时间而异,一个系统不是一下子就设计的非常完美,在有限的资源情况下一定是先解决当下最核心的问题,并预测/发现未来可能出现的问题,一步步解决最痛点的问题。也就是说系统设计是不断迭代的过程,在迭代中发现问题修复问题;即满足需求的系统是不断迭代优化出来的,不是一下子就架构的非常完美,这是一个持续的过程,个人不相信完美架构银弹。不过如果一开始就有好的基础系统设计,未来可以更容易达到一个比较满意的目标。
牛嗷嗷
2018/08/01
8510
电商前端交易型系统设计原则
【作业】2020年高等软件工程系统设计阶段思考
首先,按照国际惯例,好久不见。咋说呢,这波我自己感觉仿佛过了一年,但是翻回去一看日期才大半个月。为啥呢,这阵子太忙了,事情一个接一个,而且大都还是自己完全不擅长却又不得不做还得做的像样点的那种。不说别
HansBug
2021/01/13
3020
六年修成架构师,看他告诉你需要哪些软技能!
顾伟,普元信息的主任架构师,也是个不折不扣的程序员型架构师。这些年一直在做产品研发相关的工作,参与研发的产品方向也比较多,从传统的开发平台、服务总线、应用服务器,到这些年的IaaS、PaaS、CaaS、DevOps等;技术方向也比较杂,从一开始的纯前端,到J2EE,到插件开发,再到openstack,cloudfoundry,docker,k8s等。
技术zhai
2019/02/15
7710
【Z投稿】运维故障管理的思考:建立规范可遵循的故障管理原则
《FastDFS分布式存储实战》作者,国内第一本《Ansible中文手册》译者、Flamingo、FMS作者
Zabbix
2021/02/03
9460
IT 经理把项目带崩是因为这几点没做好
分享一个来自码哥工作中遇到的时间紧任务重,对系统不熟悉,没有产品文档,目标就是将原有系统改造成客户本地部署运行的多重困难跨团队协作项目管理差点带崩的经历。
码哥字节
2024/02/21
1120
IT 经理把项目带崩是因为这几点没做好
对开发人员有用的定律、理论、原则和模式
这篇文章包含对一些定律、原则以及模式的解释,但不提倡其中任何一个。它们的应用始终存在着争论,并且很大程度上取决于你正在做什么。
公众号_松华说
2019/12/03
5030
对开发人员有用的定律、理论、原则和模式
99%的程序员容易忽视的“系统”健康问题
对于业务同学,不管是从0到1完成一个项目,还是从1到2迭代或者维护老系统,多多少少会因为客观或非客观因素,产生一些当时可控的“负债”,随着时间的积累,那些当时以为可控的“负债”,慢慢“长大”,使得在项目随后发展的过程中,复杂度越来越高、潜在的风险越来越大。本文将阐述我对于业务负债以及身体负债的一些思考。
腾讯云开发者
2023/11/21
8402
99%的程序员容易忽视的“系统”健康问题
相关推荐
墨菲定律是运维的魔咒!
更多 >
领券
💥开发者 MCP广场重磅上线!
精选全网热门MCP server,让你的AI更好用 🚀
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档