康威定律的复苏

我们提到了康威定律作为团队设计和进化的驱动力来说至关重要。那么，究竟什么是康威定律呢？

1968年，计算机系统研究院的梅尔·康威在Datamation杂志上发表了一篇论文How Do Committees Invent？，他在这篇论文中探讨了组织结构和最终的系统设计之间的关系。这篇文章充满了闪光的见解，我们将在本章后面介绍其中一部分。这篇文章中有一句话后来被总结为康威定律：“设计系统的组织由于受到约束，这些设计往往是组织内部沟通结构的副本。”

康威是在一个开发早期电子计算机系统的组织中观察到这个现象的。在他看来，这个“定律”表明了一个组织的真实沟通路径（也就是Pflaeging提到的价值创造架构）和最终软件架构（或者是作家Allan Kelly提到的“同态力”）之间的强相关性。这种同态力将软件架构和团队结构塑造成相同的“形状”。换句话说，构建软件需要理解团队的沟通路径，以便更加实际地考虑什么样的软件架构才是可行的。如果预期中理论上的系统架构不符合组织模型的话，那么其中之一就需要做出改变。

Eric Raymond在他的The New Hacker's Dictionary一书中幽默地说道：“如果有四个小组合作开发一个编译器，那么你将得到一款具有四个步骤的编译器。”

自1968年以来，我们可以越发清晰地看到康威定律对于所有软件构建都发挥了作用。当我们不得不遵循“架构蓝图”构建软件系统的时候，我们无数次感觉到是在与架构做斗争，而非让架构协助我们驶向正确的方向。而这恰恰就是康威定律在发挥作用。

到了2015年左右，康威定律再一次复苏，这正是微服务刚刚兴起的时候。特别是ThoughtWorks的技术总监James Lewis突发奇想地提出应用“逆康威定律”，也就是说组织要根据他们想得到的软件架构来设计团队结构，而不是期望团队盲从一个被设计好的团队结构。

团队结构必须与所需的软件架构或者产生非预期设计的风险相匹配。

其中的核心观点在于，将软件架构看作一个独立的概念，认为它可以被孤立设计，然后交由任何团队来实现，这从根本上就是错误的。软件架构和团队结构的差异在所有架构类型中比比皆是，无论是客户端-服务端、SOA还是微服务架构。这也是为什么为了让团队聚焦，单体架构需要拆分（特别是，当一个没有被拆分的组件超出了任何一个团队认知极限的时候），关于这部分内容，我们将在第6章中讨论。