Conway定律

第一定律：企业沟通方式会通过系统设计表达出来沟通的问题会影响系统设计，进而影响整个系统的开发效率以及最终结果。

增加开发者的数量以跟上紧凑的进度是许多企业常见的问题，虽然增加劳动以达到增加产出的目的是有意义的，但在沟通成本上也会大大增加——随着项目或企业中的人员数量增加，沟通成本成指数级增长，它可以通过公式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

生物学家Dunbar在1992年提出了一个名为Dunbar Number的理论：灵长类动物的大脑容量与它的族群大小有关，然后推论出一些人类大脑能够维持的关系数量，例如，一个典型的人会有：

5个死党

15个信任的朋友

35个一般的朋友

150个只打过照面的朋友

所以它们与上面提到的沟通成本有关，大脑只能维持这么多的关系（在开发团队中，这个数字可能更小）。

《The Mythical Man-Month》 这本书里有一句令人难忘的话：在应用项目后期加大人员的投资，会更加拖慢它的速度。

第二定律：再多的时间也没办法让任务完美至极，但总有时间能将它完成

罗马不是一天建成的，学会先解决首要问题。

敏捷开发巨头之一Erik Hollnagel在他的书中阐述了类似的观点：问题太复杂？那么不妨忽略不必要的细节。没有足够的资源？放弃无用的功能。通过两种方式可以确保安全性：

常规安全：必须检测和消除尽可能多的错误。

非常规安全：若出现错误，要及时处理，最快恢复服务。

例如，对于像飞行系统这样复杂的系统，不管测试人员的业务多么纯熟，也会忽略一些漏洞，因此尽量去保证安全和正确性，通过不断地飞行测试，去识别安全问题，确保系统能够在出现故障时自动回复，下图显示了安全的不同解释:

在由微服务组成的系统中，每个微服务都可能停止响应，这是完全正常的，只需要确保足够的冗余和备份，这就是弹性或高可用性设计。

第三定律：线型系统和线型组织架构间有潜在的异质同态特性

创建独立的子系统，减少沟通成本。如果系统是以业务边界划分的，按照业务目标去构建小的系统或产品，整体系统将会如下图所示，即微服务架构：

团队中微服务的理念应是Inter-Operate，而不是Integrate ，Inter-Operate是指定义系统边界和接口，并为整个团队提供完整的堆栈，实现完全的自制。如此就能降低系统间的依赖性，减少通信成本。

第四定律：大系统比小系统更适用于任务分解

前面提到，人类是复杂的社会动物，人与人之间的交流是非常复杂的，当涉及到一个系统时，人们经常选择增加人力去减少复杂性，对于企业来说，该如何处理这样的沟通问题？答案是：分而治之。

看看公司内，一名经理管理的员工一般少于15个，二三线经理管理的员工要更少，因此，大企业通常会将团队拆成一个个小团队或部门减少沟通成本及管理的问题，有一些需要考虑的场景：

创业的项目很好，拿到一大笔风投，再招募更多的程序员人员太多，需要找几个经理进行管理

康威定律好告诉我们，可以从系统设计中看出组织通信的模式，每个经理要对大系统的某一小部分负责，通过这种方式，它们和更大的系统间沟通有了便捷，因此大的系统也会被拆分成一个个小系统。（微服务可以更好地服务于此）

康威定律与微服务

再来看一下康威定律是如何在半个世纪前就奠定了微服务理论基础的。

人与人之间的交流很复杂，每个人的精力是有限的，因此当问题很复杂，需要协调地去解决时，需要将组织划分进而提高沟通效率。

团队成员工作的系统设计依赖于成员之间的沟通，管理人员可以调整划分模式，实现团队之间的不同沟通方式，这也会影响系统的设计。

如果子系统有清晰的外部通信便捷，那么就可以有效地降低通信成本，响应地设计将更加适合和有效。

需要不断优化一个复杂的系统，并容错性和故障恢复率的帮助下进行优化，不要期望大而全面的设计或架构，因为它们的开发以迭代的方式发生。