精华内容
下载资源
问答
  • 康威定律

    千次阅读 2021-01-29 10:17:46
    康威定律是马尔文·康威1967提出的:“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲:产品必然是其(人员)组织沟通结构的缩影。 跨部门沟通是非常难的,系统各个模块的接口也反映了它们之间的...

    康威定律是马尔文·康威1967提出的:“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲:产品必然是其(人员)组织沟通结构的缩影。

    跨部门沟通是非常难的,系统各个模块的接口也反映了它们之间的信息流动和合作方式。

    image

    康威定律可谓软件架构设计中的第一定律,起初只是在杂志上的发表,后经过《人月神话》这本软件界圣经的引用,并命名为康威定律(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。
    线型系统和线型组织架构间有潜在的异质同态特性。

    这一定律是第一定律的具体应用。想象一下如果公司的组织架构是这样的:团队是分布式,每个团队都包含产品、研发、测试、运维等角色。而此时系统是单块的,项目沟通和协调的成本是巨大的,弄不好还会打起来。

    image

    如果将单块的系统拆分成微服务,每个团队负责自己的部分,对外提供对应的接口即可,互不干扰。系统效率将得到提升。这与软件设计中的高内聚、低耦合是相通的。

    image

    直白的说就是想要什么的系统就搭建什么样的团队,有什么样的团队就搭建什么样的系统。需要前后端分离的系统就搭建前后端分离的团队,反之,拥有前后端分离的团队,可以设计前后端分离的系统。当然,如果能统筹管理,拥有重组团队或设计系统架构的权利,那就再好不过了。通常情况下让两者形成1:1的映射关系,更加高效。

    第四定律

    The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。
    大的系统组织总是比小系统更倾向于分解。

    “话说天下大势,分久必合,合久必分。”系统越复杂,越需要增加人手,人手越多,沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级,分不同的小团队,让团队内部完成自治理,然后统一对外沟通。

    展开全文
  • 什么是康威定律

    2021-10-01 17:06:59
    康威定律是马尔文·康威1967提出的: “设计系统的架构受制于产生这些设计的组织的沟通结构。” 通俗的来讲:产品必然是其(人员)组织沟通结构的缩影。 跨部门沟通是非常难的,系统各个模块的接口也反映...

    康威定律是马尔文·康威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,再全面的测试覆盖率也无法测出所有的问题。解决方案不是消灭这些问题,是容忍一些问题的存在,然后通过适当的设计(冗余、监控、高可用设计)当问题发生时能够快速解决。

    几个开发人员的小公司,去追求微服务、去追求中台架构,这是追求完美吗?不是,是找死。

    好的架构不是买来的,也不是设计出来的,而是根据业务落地生根长期演化来的。

    在系统真正地投入生产使用之前,再好的架构都只是假设,产品越晚被使用者使用,失败的成本和风险就越高,而小步行进,通过MVP快速实验,获取客户反馈,迭代演化产品,能有效地减少失败的成本和风险。

    另外,多年的经验告诉我,架构,平台不是买来的,也不是用一个开源就能获得的,也不是设计出来,而是长期演化才能落地生根的。

    第三定律

    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),一个技术产品,一波人可以做,另一波人也可以做,到底谁做的好,真不好说,不管谁做,都给业务套上了一副手铐。”

    我刚入软件开发这个行业之初,谈的架构主要是性能,高可用等等。现在,见过无数遗留系统,特别是国内企业 IT 的现状,无数高耦合的遗留系统,不良的架构像手铐一样牢牢地限制住业务,升级替换成本非常巨大, 所以我更加关注可理解,可维护性,可扩展性,成本 。我想补充一句,创业公司创业之初获得好的架构师或技术 CTO 非常重要。

    总结

    • 架构是由组织关系来决定的。

    • 架构不仅要服务于技术,更要服务于人。

    • 没有最好的架构,只有最合适的架构。

    参考:

    展开全文
  • 今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构,之前工作过的公司eBay、携程、唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分享心得...
  • 康威定律

    千次阅读 2019-03-07 15:00:27
    前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容。 可能出乎很多...

    概述

          关于微服务的介绍,可以参考微服务那点事

          微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容。

          可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证,这就是康威定律(Conway's Law)

          screenshot screenshot

          在康威的这篇文章中,最有名的一句话就是:

    Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

          中文直译大概的意思就是:设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。看看下面的图片(来源于互联网,侵删),再想想Apple的产品、微软的产品设计,就能形象生动的理解这句话。
    screenshot

          用通俗的说法就是:组织形式等同系统设计。

          这里的系统按原作者的意思并不局限于软件系统。据说这篇文章最初投的哈佛商业评论,结果程序员屌丝的文章不入商业人士的法眼,无情被拒,康威就投到了一个编程相关的杂志,所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律(law),只是描述了作者自己的发现和总结。后来,在Brooks Law著名的人月神话中,引用这个论点,并将其“吹捧”成了现在我们熟知“康威定律”。

    康威定律详细介绍

    Mike从他的角度归纳这篇论文中的其他一些核心观点,如下:

    • 第一定律:Communication dictates design(组织沟通方式会通过系统设计表达出来)
    • 第二定律:There is never enough time to do something right, but there is always enough time to do it over(时间再多一件事情也不可能做的完美,但总有时间做完一件事情)
    • 第三定律:There is a homomorphism from the linear graph of a system to the linear graph of its design organization(线型系统和线型组织架构间有潜在的异质同态特性)        
    • 第四定律: The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems(大的系统组织总是比小系统更倾向于分解)

    人是复杂社会动物

         第一定律:Communication dictates design(组织沟通方式会通过系统设计表达出来)

          组织的沟通和系统设计之间的紧密联系,在很多别的领域有类似的阐述。对于复杂的系统,聊设计就离不开聊人与人的沟通,解决好人与人的沟通问题,才能有一个好的系统设计。相信几乎每个程序员都读过的《人月神话》(1975年,感觉都是老古董了,经典的就是经得起时间考验)里面许多观点都和这句话有异曲同工之妙。

          screenshot       screenshot

          比如《人月神话》中最著名的一句话就是

    Adding manpower to a late software project makes it later --Fred Brooks, (1975)

          Boss们都听到了吗?为了赶进度加程序员就像用水去灭油锅里的火一样(无奈大家还是前赴后继)。

          为什么?人月神话也给出了很简洁的答案:沟通成本 = n(n-1)/2,沟通成本随着项目或者组织的人员增加呈指数级增长。是的,项目管理这个算法的复杂度是O(n^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

          所以知道为什么互联网创业公司都这么小了吧,必须小啊,不然等CEO和所有人讲一遍创业的想法后,风投的钱都烧完了。

          Mike还举了一个非常有意思的理论,叫“Dunbar Number”,这是一个叫Dunbar(废话)生物学家在1992年最早提出来的。最初,他发现灵长类的大脑容量和其对应的族群大小有一定关联,进而推断出人类的大脑能维系的关系的一些有趣估计。举例来说

    • 亲密(intimate)朋友: 5
    • 信任(trusted)朋友: 15
    • 酒肉(close)朋友: 35
    • 照面(casual)朋友: 150

          screenshot

          是不是和上面的沟通成本的数字很貌似有关联?是的,我们的大脑智力只能支持我们维系这么多的关系。(大家都知道这不是程序猿擅长的领域,在开发团队里,这个值应该更小,估计和猿差不多 -_-凸 )

          沟通的问题,会带来系统设计的问题,进而影响整个系统的开发效率和最终产品结果。

    一口气吃不成胖子,先搞定能搞定的

          第二定律:There is never enough time to do something right, but there is always enough time to do it over(时间再多一件事情也不可能做的完美,但总有时间做完一件事情)       Eric Hollnagel是敏捷开发社区的泰斗之一,在他《Efficiency-Effectiveness Trade Offs》 一书中解释了类似的论点。

    Problem too complicated? Ignore details. 
    Not enough resources?Give up features.
    --Eric Hollnagel (2009)

          screenshot       screenshot

          系统越做越复杂,功能越来越多,外部市场的竞争越来越剧烈,投资人的期待越来越高。但人的智力是有上限的,即使再牛逼的人,融到钱再多也不一定招到足够多合适的人。对于一个巨复杂的系统,我们永远无法考虑周全。Eric认为,这个时候最好的解决办法竟然是——“破罐子破摔”。

          其实我们在日常开发中也经常碰到。产品经理的需求太复杂了?适当忽略一些细节,先抓主线。产品经理的需求太多了?放弃一些功能。

          据说Eric被一家航空公司请去做安全咨询顾问,复杂保证飞机飞行系统的稳定性和安全性。Eric认为做到安全有两种方式:

    • 常规的安全指的是尽可能多的发现并消除错误的部分,达到绝对安全,这是理想。
    • 另一种则是弹性安全,即使发生错误,只要及时恢复,也能正常工作,这是现实。

          对于飞机这样的复杂系统,再牛逼的人也无法考虑到漏洞的方方面面,所以Eric建议放弃打造完美系统的想法,而是通过不断的试飞,发现问题,确保问题发生时,系统能自动复原即可,而不追求飞行系统的绝对正确和安全。

          下面的图很好的解释了这个过程:
          screenshot
          听着很耳熟不是吗?这不就是 持续集成 和敏捷开发吗?的确就是。

          另一方面,这和互联网公司维护的分布式系统的弹性设计也是一个道理。对于一个分布式系统,我们几乎永远不可能找到并修复所有的bug,单元测试覆盖1000%也没有用,错误流淌在分布式系统的血液里。解决方法不是消灭这些问题,而是容忍这些问题,在问题发生时,能自动回复,微服务组成的系统,每一个微服务都可能挂掉,这是常态,我们只有有足够的冗余和备份即可。即所谓的 弹性设计(Resilience) 或者叫高可用设计(High Availability)。

    种瓜得瓜,做独立自治的字系统减少沟通成本

          第三定律:There is a homomorphism from the linear graph of a system to the linear graph of its design organization(线型系统和线型组织架构间有潜在的异质同态特性)  

            screenshot

          这是康威第一定律组织和设计间内在关系的一个具体应用。更直白的说,你想要什么样的系统,就搭建什么样的团队。如果你的团队分成前端团队,Java后台开发团队,DBA团队,运维团队,你的系统就会长成下面的样子:
          screenshot

          相反,如果你的系统是按照业务边界划分的,大家按照一个业务目标去把自己的模块做出小系统,小产品的话,你的大系统就会长成下面的样子,即微服务的架构
          screenshot

          微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口,在一个团队内全栈,让团队自治,原因就是因为如果团队按照这样的方式组建,将沟通的成本维持在系统内部,每个子系统就会更加内聚,彼此的依赖耦合能变弱,跨系统的沟通成本也就能降低。

    合久必分,分而治之

          第四定律: The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems(大的系统组织总是比小系统更倾向于分解)

          前面说了,人是复杂的社会动物,人与人的通过非常复杂。但是当我们面对复杂系统时,又往往只能通过增加人力来解决。这时,我们的组织一般是如何解决这个沟通问题的呢?Divide and conquer,分而治之。大家看看自己的公司的组织,是不是一个一线经理一般都是管理15个人以下的?二线经理再管理更少的一线?三线再管理更少的,以此类推。(这里完全没有暗示开发经理比程序猿更难管理)

          所以,一个大的组织因为沟通成本/管理问题,总为被拆分成一个个小团队。

    • 创业的想法太好了,反正风投钱多,多招点程序猿
    • 人多管不过来啊,找几个经理帮我管,我管经理
    • 最后, 康威定律 告诉我们组织沟通的方式会在系统设计上有所表达,每个经理都被赋予一定的职责去做大系统的某一小部分,他们和大系统便有了沟通的边界,所以大的系统也会因此被拆分成一个个小团队负责的小系统(微服务是一种好的模式)

    康威定律如何解释微服务的合理性

          了解了康威定律是什么,再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。

    • 人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理
    • 组织内人与人的沟通方式决定了他们参与的系统设计,管理者可以通过不同的拆分方式带来不同的团队间沟通方式,从而影响系统设计
    • 如果子系统是内聚的,和外部的沟通边界是明确的,能降低沟通成本,对应的设计也会更合理高效
    • 复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的

          带来的具体的实践建议是:

    • 我们要用一切手段提升沟通效率,比如slack,github,wiki。能2个人讲清楚的事情,就不要拉更多人,每个人每个系统都有明确的分工,出了问题知道马上找谁,避免踢皮球的问题。
    • 通过MVP的方式来设计系统,通过不断的迭代来验证优化,系统应该是弹性设计的。
    • 你想要什么样的系统设计,就架构什么样的团队,能扁平化就扁平化。最好按业务来划分团队,这样能让团队自然的自治内聚,明确的业务边界会减少和外部的沟通成本,每个小团队都对自己的模块的整个生命周期负责,没有边界不清,没有无效的扯皮,inter-operate, not integrate。
    • 做小而美的团队,人多会带来沟通的成本,让效率下降。亚马逊的Bezos有个逗趣的比喻,如果2个披萨不够一个团队吃的,那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7,8人左右(包含前后端测试交互用研等,可能身兼数职)。

          再对应下衡量微服务的标准,我们很容易会发现他们之间的密切关系:

    • 分布式服务组成的系统
    • 按照业务而不是技术来划分组织
    • 做有生命的产品而不是项目
    • Smart endpoints and dumb pipes(我的理解是强服务个体和弱通信)
    • 自动化运维(DevOps)
    • 容错
    • 快速演化

    参考资料

    展开全文
  • 康威定律 - 介绍

    千次阅读 2019-01-16 18:08:07
    前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容。 可能出乎很多...
       微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容。
    
       可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证,这就是康威定律(Conway's Law)。
       在康威的这篇文章中,最有名的一句话就是:
       Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
       中文直译大概的意思就是:设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。
       用通俗的说法就是:组织形式等同系统设计。
    

    这里的系统按原作者的意思并不局限于软件系统。据说这篇文章最初投的哈佛商业评论,结果程序员屌丝的文章不入商业人士的法眼,无情被拒,康威就投到了一个编程相关的杂志,所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律(law),只是描述了作者自己的发现和总结。后来,在Brooks Law著名的人月神话中,引用这个论点,并将其“吹捧”成了现在我们熟知“康威定律”。

    康威定律详细介绍
    Mike从他的角度归纳这篇论文中的其他一些核心观点,如下:

    第一定律
    Communication dictates design
    组织沟通方式会通过系统设计表达出来
    第二定律

    There is never enough time to do something right, but there is always enough time to do it over
    时间再多一件事情也不可能做的完美,但总有时间做完一件事情
    第三定律

    There is a homomorphism from the linear graph of a system to the linear graph of its design organization
    线型系统和线型组织架构间有潜在的异质同态特性
    第四定律

    The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
    大的系统组织总是比小系统更倾向于分解
    人是复杂社会动物
    第一定律

    Communication dictates design
    组织沟通方式决定系统设计
    组织的沟通和系统设计之间的紧密联系,在很多别的领域有类似的阐述。对于复杂的系统,聊设计就离不开聊人与人的沟通,解决好人与人的沟通问题,才能有一个好的系统设计。相信几乎每个程序员都读过的《人月神话》(1975年,感觉都是老古董了,经典的就是经得起时间考验)里面许多观点都和这句话有异曲同工之妙。

    在这里插入图片描述
    比如《人月神话》中最著名的一句话就是

    Adding manpower to a late software project makes it later --Fred Brooks, (1975)

    Boss们都听到了吗?为了赶进度加程序员就像用水去灭油锅里的火一样(无奈大家还是前赴后继)。

    为什么?人月神话也给出了很简洁的答案:沟通成本 = n(n-1)/2,沟通成本随着项目或者组织的人员增加呈指数级增长。是的,项目管理这个算法的复杂度是O(n^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
    所以知道为什么互联网创业公司都这么小了吧,必须小啊,不然等CEO和所有人讲一遍创业的想法后,风投的钱都烧完了。

    Mike还举了一个非常有意思的理论,叫“Dunbar Number”,这是一个叫Dunbar(废话)生物学家在1992年最早提出来的。最初,他发现灵长类的大脑容量和其对应的族群大小有一定关联,进而推断出人类的大脑能维系的关系的一些有趣估计。举例来说

    亲密(intimate)朋友: 5
    信任(trusted)朋友: 15
    酒肉(close)朋友: 35
    照面(casual)朋友: 150

    在这里插入图片描述
    是不是和上面的沟通成本的数字很貌似有关联?是的,我们的大脑智力只能支持我们维系这么多的关系。(大家都知道这不是程序猿擅长的领域,在开发团队里,这个值应该更小,估计和猿差不多 -_-凸 )

    沟通的问题,会带来系统设计的问题,进而影响整个系统的开发效率和最终产品结果。

    一口气吃不成胖子,先搞定能搞定的
    第二定律:

    There is never enough time to do something right, but there is always enough time to do it over
    时间再多一件事情也不可能做的完美,但总有时间做完一件事情
    Eric Hollnagel是敏捷开发社区的泰斗之一,在他《Efficiency-Effectiveness Trade Offs》 一书中解释了类似的论点。

    Problem too complicated? Ignore details.
    Not enough resources?Give up features.

    在这里插入图片描述

    系统越做越复杂,功能越来越多,外部市场的竞争越来越剧烈,投资人的期待越来越高。但人的智力是有上限的,即使再牛逼的人,融到钱再多也不一定招到足够多合适的人。对于一个巨复杂的系统,我们永远无法考虑周全。Eric认为,这个时候最好的解决办法竟然是——“破罐子破摔”。

    其实我们在日常开发中也经常碰到。产品经理的需求太复杂了?适当忽略一些细节,先抓主线。产品经理的需求太多了?放弃一些功能。

    据说Eric被一家航空公司请去做安全咨询顾问,复杂保证飞机飞行系统的稳定性和安全性。Eric认为做到安全有两种方式:

    常规的安全指的是尽可能多的发现并消除错误的部分,达到绝对安全,这是理想。
    另一种则是弹性安全,即使发生错误,只要及时恢复,也能正常工作,这是现实。
    对于飞机这样的复杂系统,再牛逼的人也无法考虑到漏洞的方方面面,所以Eric建议放弃打造完美系统的想法,而是通过不断的试飞,发现问题,确保问题发生时,系统能自动复原即可,而不追求飞行系统的绝对正确和安全。

    下面的图很好的解释了这个过程:

    在这里插入图片描述
    听着很耳熟不是吗?这不就是 持续集成 和敏捷开发吗?的确就是。

    另一方面,这和互联网公司维护的分布式系统的弹性设计也是一个道理。对于一个分布式系统,我们几乎永远不可能找到并修复所有的bug,单元测试覆盖1000%也没有用,错误流淌在分布式系统的血液里。解决方法不是消灭这些问题,而是容忍这些问题,在问题发生时,能自动回复,微服务组成的系统,每一个微服务都可能挂掉,这是常态,我们只有有足够的冗余和备份即可。即所谓的 弹性设计(Resilience) 或者叫高可用设计(High Availability)。

    种瓜得瓜,做独立自治的字系统减少沟通成本
    第三定律

    There is a homomorphism from the linear graph of a system to the linear graph of its design organization
    线型系统和线型组织架构间有潜在的异质同态特性

    在这里插入图片描述

    这是康威第一定律组织和设计间内在关系的一个具体应用。更直白的说,你想要什么样的系统,就搭建什么样的团队。如果你的团队分成前端团队,Java后台开发团队,DBA团队,运维团队,你的系统就会长成下面的样子:

    在这里插入图片描述

    相反,如果你的系统是按照业务边界划分的,大家按照一个业务目标去把自己的模块做出小系统,小产品的话,你的大系统就会长成下面的样子,即微服务的架构

    在这里插入图片描述

    微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口,在一个团队内全栈,让团队自治,原因就是因为如果团队按照这样的方式组建,将沟通的成本维持在系统内部,每个子系统就会更加内聚,彼此的依赖耦合能变弱,跨系统的沟通成本也就能降低。

    合久必分,分而治之
    第四定律

    The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
    大的系统组织总是比小系统更倾向于分解
    前面说了,人是复杂的社会动物,人与人的通过非常复杂。但是当我们面对复杂系统时,又往往只能通过增加人力来解决。这时,我们的组织一般是如何解决这个沟通问题的呢?Divide and conquer,分而治之。大家看看自己的公司的组织,是不是一个一线经理一般都是管理15个人以下的?二线经理再管理更少的一线?三线再管理更少的,以此类推。(这里完全没有暗示开发经理比程序猿更难管理)

    所以,一个大的组织因为沟通成本/管理问题,总为被拆分成一个个小团队。

    创业的想法太好了,反正风投钱多,多招点程序猿
    人多管不过来啊,找几个经理帮我管,我管经理
    最后, 康威定律 告诉我们组织沟通的方式会在系统设计上有所表达,每个经理都被赋予一定的职责去做大系统的某一小部分,他们和大系统便有了沟通的边界,所以大的系统也会因此被拆分成一个个小团队负责的小系统(微服务是一种好的模式)
    康威定律如何解释微服务的合理性
    了解了康威定律是什么,再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。

    人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理
    组织内人与人的沟通方式决定了他们参与的系统设计,管理者可以通过不同的拆分方式带来不同的团队间沟通方式,从而影响系统设计
    如果子系统是内聚的,和外部的沟通边界是明确的,能降低沟通成本,对应的设计也会更合理高效
    复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的
    带来的具体的实践建议是:

    我们要用一切手段提升沟通效率,比如slack,github,wiki。能2个人讲清楚的事情,就不要拉更多人,每个人每个系统都有明确的分工,出了问题知道马上找谁,避免踢皮球的问题。
    通过MVP的方式来设计系统,通过不断的迭代来验证优化,系统应该是弹性设计的。
    你想要什么样的系统设计,就架构什么样的团队,能扁平化就扁平化。最好按业务来划分团队,这样能让团队自然的自治内聚,明确的业务边界会减少和外部的沟通成本,每个小团队都对自己的模块的整个生命周期负责,没有边界不清,没有无效的扯皮,inter-operate, not integrate。
    做小而美的团队,人多会带来沟通的成本,让效率下降。亚马逊的Bezos有个逗趣的比喻,如果2个披萨不够一个团队吃的,那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7,8人左右(包含前后端测试交互用研等,可能身兼数职)。
    再对应下衡量微服务的标准,我们很容易会发现他们之间的密切关系:

    分布式服务组成的系统
    按照业务而不是技术来划分组织
    做有生命的产品而不是项目
    Smart endpoints and dumb pipes(我的理解是强服务个体和弱通信)
    自动化运维(DevOps)
    容错
    快速演化

    展开全文
  • 什么是康威定律? Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.– Melvin Conway(1967) ...
  • 摘要: 可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证,这就是康威定律。...
  • title toc layout ... 康威定律与微服务的关系 true blog blog 2018/07/18 10:19 {{title}} ...
  • 你好,这是【一文一点】的第4篇文章,不拘泥于篇幅字数,用一篇文章说清一个知识点。康威定律,也有反康威定律,我们结合这两个一起来说说。我曾经有段时间都理解成,反康威定律就是反对康威定律...
  • 康威定律是马尔文·康威1967提出的:“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲:产品必然是其(人员)组织沟通结构的缩影。 跨部门沟通是非常难的,系统各个模块的接口也反映了它们之间的...
  • 在划分系统时,应该多考虑 康威定律:系统架构是公司组织架构的反映。应该按照业务闭环进行系统拆分/组织架构划分,实现闭环/高内聚/低耦合,减少沟通成本。如果沟通出现问题,那么应该考虑进行系统和组织架构的...
  • 一、首先了解什么是康威定律 康威定律其实是一句格言,指出组织设计系统来反映他们自己的沟通结构。它以计算机程序员梅尔文·康威的名字命名,他于1967年提出了这个想法。他最初的措辞是: organizations which ...
  • 康威定律和技术债看研发之痛

    千次阅读 2017-03-11 20:45:03
    康威定律和技术债看研发之痛 开涛的博客2017-02-21 08:29:58技术 操作系统阅读(284)评论(0) 声明:本文由入驻搜狐公众平台的作者撰写,除搜狐官方账号外,观点仅代表作者本人,不代表搜狐立场。举报 ...
  • 所谓康威定律,来自于Melvin Conway1968年写的一篇论文,原文是Any organization that design a system (defined broadly) will produce a design whose structure is a copy of the organization's communication ...
  • 康威定律可谓软件架构设计中的第一定律,起初只是在杂志上的发表,后经过《人月神话》这本软件界圣经的引用,并命名为康威定律(Conway’s law),因此得以推广。 只通过简单的描述可能无法理解康威定律的精髓所在,...
  • 康威定律——微服务的理论基础 微服务# 系统架构 前言微服务现在大行其道,大家都在追,也都觉得很对,很多公司就算是用户量不大也都要上微服务,赶一波潮流但是似乎没有很充足的理论基础说明这是正确的,给人...
  • 1康威定律的来历 在他的职业生涯中,康威观察到一个现象:软件团队开发的产品是对公司组织架构的反映。 于是,1967 年他针对这个现象提交了一篇论文(http://www.melconway.com/Home/Committees_Paper.html)
  • 麻省理工学院和哈佛商学院研究小组发表了支持康威定律的证据,他们使用“镜像假设”作为康威定律的等效术语,发现“支持镜像假设”的有力证据,“[产品]模块化的显着差异”与“ 分布式团队倾向于开发更多模块化产品...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,625
精华内容 1,450
关键字:

康威定律