概述

康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”

通俗来讲就是：组织形式等同系统设计

我们来看看下面的图片

从这张图也可以看出：

1、亚马逊等级森严且有序
2、谷歌结构清晰，产品和部门之间却相互交错且混乱
3、Faceboot架构分散，就像一张散开的网络
4、微软内部各自占山为王，军阀作风深入骨髓
5、苹果一个人说了算
6、庞大的甲骨文，臃肿的法务部显然要比工程部门更加重要（图中的 Legal(法律)，Engineering(工程)）

多年前，有人在《第一财经周刊》尝试画了一份中国的科技公司结构图如下所示：

1、华为，技术创新引发矩阵结构变化
2、阿里巴巴，马云的影子无时无处不在
3、新浪，依托微博画了一张大饼；
4、百度崇尚简单
5、联想，大小通吃但又左右互搏
6、腾讯，产品与部门关系千丝万缕，QQ是所有产品与服务的基石

以上和今天的实际情况已经不一样了。

康威定律详细介绍

第一定律

组织沟通方式会通过系统设计表达出来。

《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = 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

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

第二定律

时间再多一件事情也不可能做的完美，但总有时间做完一件事情。

人手永远是不够的，事情永远是做不完的，但可以一件一件来。这不就是软件行业中“敏捷开发”模式所解决的问题吗。面对这样的状况，敏捷开发可以做到不断迭代、持续交付、快速验证和反馈，并持续改进。

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

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

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

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

第三定律

线型系统和线型组织架构间有潜在的异质同态特性。

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

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

第四定律

大的系统组织总是比小系统更倾向于分解。

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

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

1、创业的想法太好了，反正风投钱多，多招点程序猿
2、人多管不过来啊，找几个经理帮我管，我管经理

最后， 康威定律 告诉我们组织沟通的方式会在系统设计上有所表达，每个经理都被赋予一定的职责去做大系统的某一小部分，他们和大系统便有了沟通的边界，所以大的系统也会因此被拆分成一个个小团队负责的小系统（微服务是一种好的模式）

参考：传送