Conway's law(康威定律)

Mel Conway  康威在加利福尼亚理工学院获得物理学硕士学位，在凯斯西储大学获得数学博士学位。毕业之后，他参与了很多知名的软件项目，如 Pascal 编辑器。在他的职业生涯中，康威观察到一个现象：软件团队开发的产品是对公司组织架构的反映。

1967 年他针对这个现象提交了一篇论文。（http://www.melconway.com/Home/Conways_Law.html）给 《哈佛商业评论》。结果程序员屌丝的文章不入商业人士的法眼，无情被拒，康威就投到了一个编程相关的杂志，所以被误解为是针对软件开发的。

最初这篇文章显然不敢自称定律（law），只是描述了作者自己的发现和总结。后来，在Brooks Law著名的人月神话中，引用这个论点，并将其“吹捧”成了现在我们熟知“康威定律”。

康威定律的核心如下：

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

任何设计系统的组织，必然会产生以下设计结果：即其结构就是该组织沟通结构的写照。简单来说： 产品必然是其组织沟通结构的缩影。

 

为什么沟通会影响产品、架构等？

在《人月神话》 中提到这样一个观点：

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

为了赶进度加程序员就像用水去灭油锅里的火一样（无奈大家还是前赴后继）。

为什么会有这样的情况，《人月神话》中给出了简洁的答案：

沟通成本 = 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 Amundsen 在 《远距离条件下的康威定律——分布式世界中实现团队构建》 讲座中（http://www.infoq.com/cn/presentations/team-building-implementation-in-distributed-world ）还举了一个非常有意思的理论，叫“Dunbar Number”，这是一个叫Dunbar（废话）生物学家在1992年最早提出来的。最初，他发现灵长类的大脑容量和其对应的族群大小有一定关联，进而推断出人类的大脑能维系的关系的一些有趣估计。举例来说

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

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

 

什么样的团队，产生什么样的架构

你想要什么样的系统，就搭建什么样的团队。如果你的团队分成前端团队，Java后台开发团队，DBA团队，运维团队，你的系统就会长成下面的样子：

典型的分层架构：

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

 

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

 

 

 

参考资料：

微服务架构的理论基础 - 康威定律
https://yq.aliyun.com/articles/8611 

每个架构师都应该研究下康威定律
http://www.infoq.com/cn/articles/every-architect-should-study-conway-law