康威定律

​

什么是康威定律？

康威定律是软件工程和组织设计中的一个基本原则，描述了组织的沟通结构与其创建的系统之间的关系。该定律指出，任何系统都受限于反映创建它的组织的沟通模式。

“设计系统的组织受限于产生与其沟通结构相似的设计。” — 梅尔文·康威

直觉很简单：人们能够沟通什么，就能够构建什么。如果你的工程团队组织成独立的前端和后端组，沟通很少，那么你的系统很可能会产生相应的分离——在两者之间有定义的API边界。如果团队围绕业务能力组织，系统也会倾向于反映这种结构。 这一定律对于我们如何设计组织、架构系统以及思考组织变革具有深远的意义。

​

康威定律的三层理解

• 入门: 认识到团队边界往往成为系统边界。如果你想改变系统边界，就需要不同的团队结构。
• 实践: 有意识地运用康威定律——创建与所需系统架构匹配的团队结构。这有时被称为”逆康威策略”。
• 进阶: 理解康威定律在多个层面起作用——部门、团队，甚至个人开发者都有其个人”架构”体现在代码中。

​

起源

梅尔文·康威（出生于1934年）是一位美国计算机科学家和程序员，于1957年通过一篇名为”委员会如何发明？“的论文提出了这一概念。该论文后来被精简并于1967年重新发布为”康威定律”。 康威的洞察来自于观察委员会和组织如何设计系统。他注意到，最终系统的结构不可避免地反映了创建它的群体的结构。这一观察此后在各个行业和数十年中得到了无数次验证。 “康威定律”一词是由作者诺曼·F·内曼于1968年在一篇出版物中首创的，尽管这一原则完全是康威的原创。

​

核心要点

​

应用场景

​

经典案例

​

MIME协议

1974年，梅尔文·康威写了一篇著名的备忘录（后来称为”康威推论”），预测一个联邦数据共享标准会发生什么。他写道：“如果一个联邦机构的数据处理项目足够重要，产生的系统将具有联邦机构式的结构。” 这一预测在IETF开发MIME电子邮件标准时得到了著名的验证。尽管是一个技术标准，但MIME实际上反映了创建它的公司的组织结构。每家公司的电子邮件系统都有自己的怪癖，标准本质上将这些组织差异编码到技术协议中。 教训：当多个组织协作开发一个系统时，最终设计反映了所有组织的沟通结构——这往往是一系列遗留模式的拼凑。

​

边界与失效场景

法则不适用的场景：

• 强大的架构领导力: 一位非常有影响力的架构师或CTO有时可以强加一个与组织结构不同的系统结构，至少是暂时的。
• 外部约束: 监管要求、客户指令或遗留系统集成可以超越组织对架构的影响。
• 小团队: 非常小的团队（不到5-8人）可以保持非正式的沟通，不会施加僵化的结构约束。

常见误用：

• 用康威定律作为借口: 一些团队声称由于团队结构”无法”创建某些架构——而不尝试改变结构。
• 在重组期间忽视它: 组织经常在不考虑对现有系统影响的情况下进行重组，导致架构与团队不对齐。
• 过度应用该定律: 并非每个代码模块都反映特定的人；有些代码确实是通用的。

​

常见误区

​

相关概念

​

一句话总结