有这样一个故事：某公司由三个团队共同开发一个程序，结果完成的程序恰好被分成了三大块。并没有谁规定要这样做，但团队的划分方式就原封不动地成了软件的形态。
像这样，设计系统的组织的沟通结构会直接反映在该系统结构上的观察，被称为“康威定律（Conway's Law）”。在开发者之间，它也常被概括为“看组织架构图，就能看出软件结构”。
本文将依次介绍康威定律从何而来、为什么会出现这种情况、它实际上以怎样的形式表现出来，以及反过来利用这一定律的方法。
理解康威定律
康威定律从何而来
这一定律的名称来自美国计算机科学家梅尔文·康威（Melvin Conway）。他在1967年写了一篇题为《委员会是如何发明的？》（How Do Committees Invent?）的文章，这篇文章未能在一家商业杂志上刊登，之后于1968年发表在计算机杂志《Datamation》上。
康威在文中主张：“设计系统的组织，必然会产生与该组织沟通结构相同的设计。”这里的系统并不仅限于软件，而是广泛地指人们共同设计的一切事物。
以“康威定律”之名让这一观点广为人知的，是弗雷德里克·布鲁克斯（Frederick Brooks）。他在1975年出版的软件开发经典著作《人月神话》（The Mythical Man-Month）中介绍了这一观察，此后康威定律便成了开发领域的常识。
为什么组织的形态会反映在设计中
大型系统无法由一个人独自完成，因此要由许多人和团队分工负责。一旦分工，就必须确定各部分相互衔接的地方，也就是接口；而要确定这些接口，负责人之间就必须相互沟通。
然而，人与人之间的交流并不是在任何地方都同样容易发生。在同一个团队内，可以随时提问和修改；但与其他团队或其他部门之间，则需要安排会议、往来文件。于是，沟通容易的地方被紧紧地捆在一起，沟通困难的地方则被生硬的边界隔开。
结果，系统的边界线往往不是画在技术上最合适的位置，而是沿着人们便于沟通的地方画出来。康威定律与其说是设计者意志不足造成的问题，不如说更接近于共同工作的方式所产生的自然结果。
随着时间推移，这些边界会变得更加牢固。每个被划分出来的部分都有了负责的团队，而每个团队都想守住自己的那一份，结果要改变结构，就不得不连组织也一起改变。因此有人说，越是老旧的系统，越会像化石一样留下这家公司历次组织调整的痕迹。
康威定律的表现形式
一个常见的例子是公司网站。访问者以为自己看的是一家公司的网站，但在各个菜单之间切换时，常常会发现每个部门的设计和措辞都各不相同。这是因为网站是按照公司内部的部门划分，而不是按照顾客的需求来组织的。
在多家公司共同参与的大型项目中，也会出现类似的情况。各家承包商分别开发自己负责的部分，结果每个部分单独运行良好，但在相互衔接的地方，却经常暴露出数据格式不匹配、同一功能被重复开发等问题。边界越多，填补这些缝隙所需的时间和费用也会随之增加。
这一定律也得到了研究的证实。2012年，美国哈佛商学院的研究人员比较了功能相同的软件，发现与紧密协作的公司团队开发的产品相比，分散在各地的开源开发者开发的产品呈现出划分更细的模块化结构。研究人员把这视为支持组织与产品相互映照的“镜像假说”的证据。
反过来利用康威定律
既然康威定律无法回避，也可以反过来，先按照想要的设计来组建组织。这被称为“逆康威策略（Inverse Conway Maneuver）”，在2010年代的软件业界得到了广泛讨论。
例如，如果想把服务拆分成小的独立单元，就为每个单元分别组建一个从头到尾负责到底的小团队。亚马逊强调团队要小到两个披萨就能吃饱的说法，也与这一思路相通。
不过，改变组织并不会让所有问题自然而然地解决。团队划分得过细，团队之间的协调反而可能增加，因此需要把系统的结构和人的结构放在一起，持续地加以审视。
康威定律提醒我们，看似技术问题的背后，往往隐藏着人的问题。想要打造好的系统，就不能只看代码，而要先看看编写这些代码的人是如何相互沟通的。
先回头审视我们共同工作的方式，这正是打造更好系统的第一步。
