墨菲定律(设计系统)和康威定律(系统划分)
在设计系统时,应该多考虑 墨菲定律:
- 任何事物都没有表面看起来那么简单。
- 所有的事都会比你预计的时间长。
- 可能出错的事总会出错。
- 如果你担心某种情况发生,那么他就更有可能发生。
在划分系统时,应该多考虑 康威定律:
- 系统架构是公司组织架构的反映。
- 应该按照业务闭环进行系统拆分/组织架构划分,实现闭环/高内聚/低耦合,减少沟通成本。
- 如果沟通出现问题,那么应该考虑进行系统和组织架构的调整。
- 在合适时机进行系统拆分,不要一开始就把系统/服务拆的非常细,虽然闭环,但是每个人维护的系统多,维护成本高。
墨菲定律
墨菲定律本质是:“小概率事件在大量独立重复试验的情况下是必然发生”。理解为,让你对自己在生活工作中,对想到可能出错的地方一定要多加重视不要心存侥幸。
查理芒格曾说过:如果我知道我会死在哪里,我就永远不去那个地方。这就是一种降低概率的做法。
相反,一个更广泛的法则——吸引力法则。这个法则不像墨菲定律只说,坏的事情一定会发生,它也会告诉你,如果你一直思考正向积极且是你想实现的梦想,那么好事也一定发生。
2014年在世界各国热映的电影《星际穿越》里,男主角库珀的女儿叫墨菲 。
影片开始部分,库珀和他的儿子女儿开车去学校,路上车子出现了爆胎,库珀的儿子说:墨菲定律。女儿很生气,问父亲为什么他和妈妈以坏事给她起名字。
这里有个概念叫“墨菲定律”,也有个同名书叫《墨菲定律》,意思就是:凡事只要有可能出错,那就一定会出错。
这是美国爱德华兹空军基地的上尉工程师爱德华·墨菲 总结的,但总结的依据不过时他经历的一次事故罢了:
1949年,他和他的上司斯塔普少校,在一次火箭减速超重试验中,因仪器失灵发生了事故。爱德华·墨菲 发现,测量仪表被一个技术人员装反了。
由此,他得出的教训是:
如果做某项工作有多种方法,而其中有一种方法将导致事故,那么一定有人会按这种方法去做。
康威定律
Soft skills are always hard than hard skills. 软技能比硬技能难。
老板听说最近流行“微服务”,问架构师咱们的系统要不要来一套?老板又听说最近流行“中台系统”,问架构师咱们要不要搞起来?其实,这些问题不用老板问,关注技术发展趋势的架构师每当听到新的技术或解决方案,都会暗中思忖是否应用到系统中。然而,用或不用,总不能凭感觉吧。此时,如果你能灵活运用康威定律,那么做出的判断将更加完美。
康威定律是马尔文·康威1967提出的:“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲:产品必然是其(人员)组织沟通结构的缩影。
跨部门沟通是非常难的,系统各个模块的接口也反映了它们之间的信息流动和合作方式。
康威定律可谓软件架构设计中的第一定律,起初只是在杂志上的发表,后经过《人月神话》这本软件界圣经的引用,并命名为康威定律(Conway’s law),因此得以推广。
只通过简单的描述可能无法理解康威定律的精髓所在,原文中康威定律可总结为四个定律:
- 第一定律 组织沟通方式会通过系统设计表达出来。
- 第二定律 时间再多一件事情也不可能做的完美,但总有时间做完一件事情。
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性。
- 第四定律 大的系统组织总是比小系统更倾向于分解。
第一定律
Communication dictates design。
组织沟通方式决定系统设计。
这条定律重点是讲组织架构和沟通对系统设计的影响。组织的沟通和系统的设计之间紧密相连,特别是复杂系统,解决好人与人的沟通才能有一个更好的系统设计。
《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律:沟通成本 = n(n-1)/2。举例说明一下:
- 5人项目组,需要沟通的渠道是 5*(5–1)/2 = 10
- 15人项目组,需要沟通的渠道是15*(15–1)/2 = 105
- 50人项目组,需要沟通的渠道是50*(50–1)/2 = 1,225
- 150人项目组,需要沟通的渠道是150*(150–1)/2 = 11,175
这也是为什么互联网公司都追求小团队的原因之一。沟通的问题会带来系统设计的问题,进而影响整个系统的开发效率和最终产品结果。
第二定律
There is never enough time to do something right, but there is always enough time to do it over。
时间再多一件事情也不可能做的完美,但总有时间做完一件事情。
人手永远是不够的,事情永远是做不完的,但可以一件一件来。这不就是软件行业中“敏捷开发”模式所解决的问题吗。面对这样的状况,敏捷开发可以做到不断迭代、持续交付、快速验证和反馈,并持续改进。
再牛的开发也会写出bug,再全面的测试覆盖率也无法测出所有的问题。解决方案不是消灭这些问题,是容忍一些问题的存在,然后通过适当的设计(冗余、监控、高可用设计)当问题发生时能够快速解决。
几个开发人员的小公司,去追求微服务、去追求中台架构,这是追求完美吗?不是,是找死。
好的架构不是买来的,也不是设计出来的,而是根据业务落地生根长期演化来的。
第三定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization。
线型系统和线型组织架构间有潜在的异质同态特性。
这一定律是第一定律的具体应用。想象一下如果公司的组织架构是这样的:团队是分布式,每个团队都包含产品、研发、测试、运维等角色。而此时系统是单块的,项目沟通和协调的成本是巨大的,弄不好还会打起来。
如果将单块的系统拆分成微服务,每个团队负责自己的部分,对外提供对应的接口即可,互不干扰。系统效率将得到提升。这与软件设计中的高内聚、低耦合是相通的。
直白的说就是想要什么的系统就搭建什么样的团队,有什么样的团队就搭建什么样的系统。需要前后端分离的系统就搭建前后端分离的团队,反之,拥有前后端分离的团队,可以设计前后端分离的系统。当然,如果能统筹管理,拥有重组团队或设计系统架构的权利,那就再好不过了。通常情况下让两者形成1:1的映射关系,更加高效。
第四定律
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。
大的系统组织总是比小系统更倾向于分解。
“话说天下大势,分久必合,合久必分。”系统越复杂,越需要增加人手,人手越多,沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级,分不同的小团队,让团队内部完成自治理,然后统一对外沟通。
小结
架构不仅仅需要技术,在大公司尤其需要政治,所谓的架构的政治。
杨波老师曾在他的文章《每个架构师都应该研究下康威定律》中提到:“政治指的是和他人协作将事情搞定的艺术,架构是一种社交活动,在技术的世界里,个人主义很容易被打败,即使你的目的是好的技术是最优的,技术决策是政治决策(technical decisions are political decisions),一个技术产品,一波人可以做,另一波人也可以做,到底谁做的好,真不好说,不管谁做,都给业务套上了一副手铐。”
最近阅读了架构之美,其中康威定律印象深刻,于是查阅了相关资料,再根据自己这么多年的开发架构经验,总结一下心得。
首先来看一下这个定律的原文:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
大概翻译下就是设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。
康威定律被视为微服务架构的理论基础,是有一定的根据的,主要有以下几点:
1.把一个大的系统分成一个个小的业务模块,每个业务模块由对应的小团队来负责而且各个小团队都是独立的,所以在分模块时要按业务而不是技术来划分。
2.避免过度设计。一个系统初级是不可能大而全,十分完美,它必须是有一个演进进程,所以刚开始能保持可移植性、高扩展性即可。保持弹性设计。
3.各微服务应该都有自己独立的数据库和资源,避免耦合在一起。
4.各微服务对外提供的接口尽量的兼容各种不同的技术和开发语言。
5.专注产品的生命力,而不是为了项目而技术。所以技术人员也有必要对业务有一定的理解。
引用:
https://www.choupangxia.com/2019/10/10/%e5%ba%b7%e5%a8%81%e5%ae%9a%e5%be%8b%ef%bc%8c%e4%bd%9c%e4%b8%ba%e6%9e%b6%e6%9e%84%e5%b8%88%e8%bf%98%e4%b8%8d%e4%bc%9a%e7%81%b5%e6%b4%bb%e8%bf%90%e7%94%a8%ef%bc%9f/
https://blog.csdn.net/guotufu/article/details/80287768
墨菲定律(设计系统)和康威定律(系统划分)相关推荐
- 康威定律对架构设计的指导意义
什么是康威定律? Conway's law: Organizations which design systems are constrained to produce designs which a ...
- 高级程序员必会的程序设计原则 —— 墨菲定律及防呆设计
前言 如果你或你带领的团队经常会写出一些BUG,日常不是在解决BUG就是在解决BUG的路上,那么你的项目一定是应验了墨菲定律,并且在开发时并没有足够考虑防呆设计.团队越是疲于奔命,错的越是多. 简记 ...
- 墨菲定律、二八法则、马太效应、手表定理、“不值得”定律等左右人生的金科玉律。
一. 墨菲定律 1949年,一位名叫墨菲的空军上尉工程师,认为他的某位同事是个倒霉蛋,不经意间开了句玩笑:"如果一件事情有可能被弄糟,让他去做就一定会弄糟." 这句话迅速流传, ...
- 从黑天鹅事件到墨菲定律
摘要:软件系统的稳定性,主要决定于整体的系统架构设计,然而也不可忽略编程的细节,正所谓"千里之堤,溃于蚁穴",一旦考虑不周,看似无关紧要的代码片段可能会带来整体软件系统的崩溃.本文 ...
- 《墨菲定律(Murphy‘s Law)》(Yanlz+Unity+SteamVR+云技术+5G+AI=VR云游戏=黄金法则+生存智慧+马太效应+口红效应+羊群效应+二八法则+人工智能+立钻哥哥+==)
<墨菲定律> <墨菲定律> 版本 作者 参与者 完成日期 备注 YanlzLaw_Murphy_V01_1.0 严立钻 2019.10.01 ##<墨菲定律>发布说 ...
- 墨菲定律 二八法则 马太效应 手表定理
最近使用 日志 相册 群组 分享 礼物 投票 好友买卖 抢车位 活动 班级 课程 抢车位 活动 班级 课程 管理我的应用 (10) 浏览更多应用 隐私设置 帐户设置 应用设置 搜索同学 搜索同事 高级 ...
- 墨菲定律、二八法则、马太效应、彼得原理、酒与污水定律、水桶定律、蘑菇管理原理等13条是左右人生的金科玉律。...
墨菲定律.二八法则.马太效应.手表定理."不值得"定律.彼得原理.零和游戏.华盛顿合作规律.酒与污水定律.水桶定律.蘑菇管理原理.钱的问题.奥卡姆剃刀等13条是左右人生的金科玉律. ...
- 墨菲定律、二八法则、马太效应、手表定理、“不值得”定律、彼得原理、零和游戏、华盛顿合作规律、酒与污水定律、水桶定律、蘑菇管理原理、钱的问题、奥卡姆剃刀等13条是左右人生的金科玉律。
一.墨菲定律 1949年,一位名叫墨菲的空军上尉工程师,认为他的某位同事是个倒霉蛋,不经意间开了句玩笑:"如果一件事情有可能被弄糟,让他去做就一定会弄糟." 这句话迅速流传,并 ...
- 找规律:墨菲定律、欧姆定律、帕金森定律、马太效应
一.墨菲定律 1949年,一位名叫墨菲的空军上尉工程师,认为他的某位同事是个倒霉蛋,不经意间开了句玩笑:"如果一件事情有可能被弄糟,让他去做就一定会弄糟." 这句话迅速流传,并扩散 ...
- 墨菲定律、二八法则、马太效应、手表定理、“不值得”定律、彼得原理、零和游戏、华盛顿合作规律、酒与污水定律、水桶定律、蘑菇管理原理、钱的问题、奥卡姆剃刀等13条是左右人生的金科玉律
转载地址:http://blog.csdn.net/byxdaz/article/details/3981125 墨菲定律.二八法则.马太效应.手表定理."不值得"定律.彼得原理. ...
最新文章
- R语言I绘制等高线图
- mysql实验总结存在问题_mysql表分区实验总结
- python ——两个队列实现一个栈两个栈实现一个队列
- JS重写Alert方法
- SharePoint 2010设计(Design)权限能操作的网站操作菜单项
- linux input输入子系统分析《四》:input子系统整体流程全面分析
- c语言如何引用参数,关于exec:如何在C语言中使用适当的参数调用execl()?
- 算法题解:找出包含给定字符的最小窗口(枚举的一般方法)
- 大数据可视化平台有什么特点
- pandas 第八章 文本数据
- hadoop 8088端口网页无法打开的原因分析
- 大学英语综合教程四 Unit 3 课文内容英译中 中英翻译
- 网页缩放,页面展示比例不变
- 2022年G2电站锅炉司炉操作证考试题库及答案
- 亚马逊、OZON、敦煌、MANO等跨境电商平台测评养号需要注意什么?
- Navicat For MySQL的简单使用(一)
- mstsc登录xubuntu16.04
- 快上车,老司机带你实现后台录像功能
- 淘宝的字体也改变了(今天)
- 推荐一款超级下载利器工具,突破网盘的下载限制
热门文章
- c语言综合编程训练,C语言综合编程训练.ppt
- 兄弟MFC-7480D打印机墨粉清零方法(图解)
- 048-Python测试题03
- 虾米网签到脚本——Python实现
- 医药行业的数据分析,我们需要了解什么?
- AD生成Gerbee的输出文件类型
- 1967. 作为子字符串出现在单词中的字符串数目字符串模式匹配-kmp算法和kmp优化算法(双百代码)
- 基于iview的Upload上传组件支持图片压缩和文档预览,整合七牛云、腾讯云
- php -v 报错error while loading shared libraries: libonig.so.5:cannot open share directory
- 虚继承是什么意思_面试题干货在此