本文共 2156 字，大约阅读时间需要 7 分钟。

Mel Conway（个人主页：http://www.melconway.com/Home/Home.html）康威在加利福尼亚理工学院获得物理学硕士学位，在凯斯西储大学获得数学博士学位。毕业之后，他参与了很多知名的软件项目，如 Pascal 编辑器。

1康威定律的来历

在他的职业生涯中，康威观察到一个现象：软件团队开发的产品是对公司组织架构的反映。

于是，1967 年他针对这个现象提交了一篇论文（http://www.melconway.com/Home/Committees_Paper.html）给 《哈佛商业评论》。结果他的文章被该杂志无情被拒，理由是他的论文没有证明他的论点。康威最后投到了一个编程相关的杂志，并于1968年4月发表。

最初这篇文章显然不敢自称定律（law），只是描述了作者自己的发现和总结。后来，在Brooks Law著名的人月神话中，引用这个论点，并将其称之为"Conway's Law."（“康威定律”），自此，康威定律的名字就这么来了。

2 康威定律的内容

康威定律的核心论点是：

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

任何设计系统的组织，其组织沟通方式会通过系统设计表达出来。

组织沟通与设计是紧密关联的。人是复杂的社会动物，对于复杂的系统，解决好沟通问题是拥有良好的设计的前提。微服务架构好比由多个小而独立的团队组成的组织，这样可以保证创建的服务彼此独立以及架构快速优化。设计微服务架构的人，为了想要这样的系统架构，反推出了这样的组织结构与之匹配。

康威定律还有一些引申内容：

1）There is never enough time to do something right, but there is always enough time to do it over

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

       其中：敏捷开发巨头之一Erik Hollnagel （2009）在他的书中阐述了类似的观点：

                1）问题太复杂？那么不妨忽略不必要的细节；

                2）没有足够的资源？放弃无用的功能；

2）There is a homomorphism from the linear graph of a system to the linear graph of its design organization

线型系统和线型组织架构间有潜在的异质同态特性。 其实就是想要什么样的系统架构就搭建什么样的团队。

3）The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems

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

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

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

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

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

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

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

典型的分层架构：

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

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

参考：

http://www.melconway.com/Home/Committees_Paper.html

https://www.sohu.com/a/215574765_717586

转载地址：https://blog.csdn.net/lclfans1983/article/details/115659312 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！