康威定律说的是什么
康威定律指出，设计系统的组织会把自身的沟通结构映射到系统结构上：团队之间怎么沟通，接口边界就大致长成什么样。它的实用价值在于反向使用——当代码边界与团队边界明显错位时，架构摩擦通常能从这里找到解释，例如某个模块被多个团队交叉修改，评审冲突与接口反复就会出现。相应的调整手段称为逆康威：按目标架构调整团队与所有权边界。
基本要点
| 原意 | 组织产出的设计与其沟通结构同构 |
|---|---|
| 观察对象 | 代码所有权与团队边界是否对齐 |
| 诊断信号 | 一个模块被多个团队交叉修改，接口频繁变更 |
| 调整手段 | 逆康威：按目标架构调整团队边界与所有权 |
典型使用场景
- 模块反复改接口：查看该模块的贡献者分布，确认是否归属多个团队
- 评审冲突频发：代码归属与团队职责不一致时，决策难以收敛
- 平台能力建设：先确定谁是使用者与维护者，再定义平台边界
- 团队划分调整：按目标架构设计沟通路径，而不是按历史人员安排
- 服务拆分评估：拆分方案与团队组织结构对照，避免出现无人负责的边界
错位信号示例
错位信号示例
# 观察：模块 M 上季度由 6 名开发者交叉修改，归属 3 个团队
表现：评审反复、接口频繁变更、缺陷集中在集成处
推断：代码边界与团队边界错位
候选动作：明确单一归属，或按目标架构重新划分模块与团队错位类型与处理
| 错位表现 | 可能原因 | 处理方向 |
|---|---|---|
| 一个模块多团队交叉修改 | 边界与职责不匹配 | 明确单一归属，或拆分为各自负责的部分 |
| 团队负责的模块彼此强耦合 | 沟通结构未对齐架构 | 调整归属使边界与接口同时收敛 |
| 接口频繁变更 | 缺少共同维护者 | 设立跨团队接口负责人与变更流程 |
| 平台无人维护 | 只被使用未被归属 | 明确平台团队与使用者代表 |
| 频繁重组团队 | 边界随组织震荡 | 重组需与架构边界同步评估 |
康威定律是解释性工具而不是唯一原因：出现接口摩擦时，先核对沟通路径与所有权证据，再考虑组织调整。把所有架构问题都归因于组织结构，容易做出错误的干预。
频繁重组团队同样有成本：系统边界会随组织反复震荡，接口与所有权需要不断重划。调整前先确认当前错位是否稳定存在，而不是一次性的项目协作。
落地检查清单
- 每个模块有明确的归属团队
- 跨团队协作的接口有共同维护者与变更流程
- 组织调整前评估对代码边界的影响
- 用提交历史作为所有权判定的证据，而非仅凭印象