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
原文地址:http://www.cnblogs.com/ghj1976/p/5703462.html
.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注