每天一条软件法则：康威定律

vibe coding已让编码变得不再是问题，但是具备良好的软件思维却比以往更加重要，每天更新一条软件法则，让我们一起进步一点点。

第 1/56 条
1️⃣ Conway’s Law（康威定律）

2️⃣ 核心定义
它的核心意思可以转述为：一个组织最终设计出来的系统，往往会长得像这个组织内部的沟通方式和协作边界。

3️⃣ 解决的问题
它帮助我们解释一个常见现象：为什么很多系统的问题，表面看是“架构问题”，根子其实是“团队协作问题”。当团队按职能割裂、沟通成本高、责任边界模糊时，系统也容易被切成彼此割裂、接口生硬、集成痛苦的样子。

4️⃣ 软件工程实践案例
一家公司把研发分成前端组、后端组、数据库组，各组分别排期、分别考核。结果做出来的产品也天然分成三层，各层之间靠大量接口协调，联调很慢，谁都能说“问题不在我这层”。后来公司把团队改成面向业务能力的跨职能小队，比如“支付小队”“订单小队”，每队同时拥有前后端和数据能力，系统边界也随之更贴近业务能力，联调成本明显下降。

5️⃣ 一条建议
今天就做一次“组织结构对照架构图”检查：把你的团队沟通边界画出来，再和系统模块边界对照，看它们是不是在互相强化。康威定律的常见误用，是把它理解成“架构只能被组织决定”；更准确的边界是：它描述的是强趋势，不是宿命。你可以通过重组协作方式、明确 ownership、建立跨职能团队，反过来塑造想要的架构。

6️⃣ 思考题
如果你现在希望系统从“大一统单体”逐步演进成“按业务能力拆分的模块或服务”，那你的团队分工、会议方式和责任边界，哪些地方也必须一起改变？