现实中的康威推论——IoT系统为例
坊间一直流传着“康威定律”的概念，但是都是鲜有人能说出真实的反应这一“定律”的例子。本文则尝试弥补这一空缺。
本文本为几部分：
- 康威推论的历史：有必要了解它的历史
- 康威推论的定义：《人月神话》也只是转载康威的话
- 康威推论的例子：我的真实经历
- 启示
康威推论的历史
1967年，一位名叫梅尔文康威（Melvin Conway）的早期计算机科学家、程序员及黑客向《哈佛商业评论》提交了一篇名为“组织是如何进行发明创造的？”的文章，但是立刻被退稿了，理由是他“没能证明该理论”。
对于软件设计界来说，幸运的是这篇文章随后被Datamation杂志（当时一流的IT杂志）接受，并于1968年发表。后来，Fred Brooks在其开创性作品《人月神话》中，将康威的某些理论归纳为“康威定律”，这个名字就这样流传了下来。
以文内容来自：《软件之道——软件开发争议问题剖析》。
康威推论的定义
我们来看看康威推论的原文 How Do Committees Invent? (1968) 最后的总结：
The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
按《软件之道》里的大白话来说就是：
任何组织设计出来的系统（此处指广义的系统）的结构都会照搬这个组织的沟通。
说实在的，如果没有经历过，我说的以下两个例子，真心很难体会到康威所表达的。下面，是两个现实鲜活的例子，我正在经历的。
康威推论的例证
例证一：错误码的设计
背景是某团队针对同一业务，有Android和iOS两个平台的SDK。
Android SDK和iOS SDK开发人员，他们对于同一业务错误，设计出了两套装错误码。比如对于登录时用户名或密码错误，Android给出的错误码是230，而iOS给出的错误码则是8100。
为什么会出现两套装错误码系统呢？明明可以使用一套装就可以了。当然可能会有历史原因。但是据我观察，可以肯定的是，他们在设计软件时，并没有就“错误码”达成共识。
有趣的是，他们是同一个团队。居然还会出现康威现象。如果康威推论是正确的，那么，即使同一个团队下，也会出现不同的沟通结构。
如果这个例证有些牵强，下面这个例证更能说明事情。
例证二：IoT系统的设计
IoT系统有其特殊性。通常它需要进行硬件端、移动端（App）、云端这三端的配合才能更好的完成事情。以空调为例：
2017年前，硬件端和移动端是（相当于，其实不是）一个团队，而云端则是由另一个公司负责。而真正业务的决定权在硬件端和移动端。所以，平时沟通上，只有硬件端和移动端的事，云端只不过是负责转发。所以，云端的系统设计的最终结果就是一个管道：硬件端给我什么，我就直接转给移动端，移动端给我什么，我就直接转给硬件端。如下图：
这样的系统意味着什么呢？移动端除了要负责展示逻辑，还要对硬件端的细节了解，比如了解某某字段的某些分别代表什么意思。这直接导致整个系统无法快速适应业务的变化。因为硬件端和移动端做了太多的事情。懂点技术的人都知道，硬件端和移动端的修改，周期长！有时硬件端修改还不好实现。
我将这样系统称为管道系统设计。
2017年，这家公司意识到云端的重要性。接而将云端的业务接管过来。这时，云端才慢慢地有更多的话语权。也就有了想要理解硬件的“欲望”。
再后来，云端开始做设备影子（IoT系统的核心）、大数据等都需要理解硬件。这时的云端不再是一个管道系统：
看吧。这三端的系统结构真的就照搬了它们的沟通结构。我作为一个旁观者和参与者，对于康威推论，体会如此深刻。
启示
关于康威的那句话，是推论，还是定律。我个人认为还只是推论，不能以“定律”来定义。但是坊间流传的都是“康威定律”。我也很是奇怪。但是不重要了。重要的是它给我们带来了什么启示。
- 当我们发现，系统设计不合理时，我们可以考虑是不是组织的沟通结构出了问题
- 技术Leader或架构师应该理解系统结构，并设计组织的沟通结构。另一个角度说，不了解技术的人，我很好奇他们是如何管理好一个技术团队，比如马云、贝佐斯。
- 组织构架应该更灵活，以适应不同的系统架构，不同的沟通结构
- 根据系统架构来决定组织架构，而不是根据权力分配
以上，只是启示。具体操作还是要看当时的组织环境和上下文。大家且行且珍惜。
End
