康威定律

康威定律是马尔文·康威1967提出的：

“ 设计系统的架构受制于产生这些设计的组织的沟通结构。”

换句话说： 产品必然是其（人员）组织沟通结构的缩影 ，一个组织的沟通结构和管理结构会直接影响到它所构建的系统或产品架构。

1、四大定律

康威定律可谓软件架构设计中的第一定律，起初只是在杂志上的发表，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。

只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四个定律：

1. 组织沟通方式决定系统设计
2. 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
3. 线型系统和线型组织架构间有潜在的异质同态特性
4. 大的系统组织总是比小系统更倾向于分解

1.1、第一定律

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

这也是为什么互联网公司都追求小团队的原因之一，沟通的问题会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。

1.2、第二定律

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

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

再牛的开发也会写出bug，再全面的测试覆盖率也无法测出所有的问题。解决方案不是消灭这些问题，是容忍一些问题的存在，然后通过适当的设计（冗余、监控、高可用设计）当问题发生时能够快速解决。

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

在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。另外，多年的经验告诉我，架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的。

因此，对于体系足够庞大的业务，将他的公司买下来，远远比将他的系统买下来更加可靠。因为建设对应人员架构体系，仍需要你自己去探索

1.3、第三定律

There is a homomorphism from the linear graph of a system to thelinear graph of its design organization。

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

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

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

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

1.4、第四定律

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

“话说天下大势，分久必合，合久必分。”

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

架构不仅仅需要技术，在大公司尤其需要政治，所谓的架构的政治。 杨波老师曾在他的文章《每个架构师都应该研究下康威定律》中提到：

“政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。”

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

1.5、总结

• 架构是由组织关系来决定的。
• 架构不仅要服务于技术，更要服务于人。
• 没有最好的架构，只有最合适的架构。

2、组织架构

基于康威理论，也就是说当业务达到一定规模，逐渐开始拆分组织架构体系的时候。打造微服务架构，每个团队负责自己的部分，配备相应的开发、测试运维职责的人，对外提供对应的接口，互不干扰，系统效率将得到提升。

其优势总结如下：

1. 增强业务理解
   • 团队成员专注于特定业务，可以更深入的了解该领域具体需求和可能遇到的挑战，从而能够更加有效的解决问题
2. 促进跨职能合作
   • 业务领域团队包含了开发、测试、运维等成员，有助于打破传统意义上的孤岛，促进不同角色之间的协作
3. 提高响应速度
   • 业务领域团队可以直接对业务需求的变化做出快速反应，因为他们拥有完成任务所需要的所有技能和资源
4. 减少沟通成本
   • 因为团队成员已经熟悉了特定领域的知识，所以内部沟通更加高效
5. 增强责任感和归属感
6. 更好的产品和服务
   • 由于团队成员能够更深入地理解用户的需求，并且能够在整个产品生命周期中保持一致的关注，因此可以提供更加高质量和更加符合市场需求的产品和服务