Open hughfenghen opened 8 months ago
引用自阮一峰周刊 https://www.ruanyifeng.com/blog/2024/03/weekly-issue-291.html
几乎所有我喜欢的软件架构师，都认同康威定律（Conway Law），认为这个定律非常重要，足以影响到所有系统。而且，你没法与之抗争，想要抗拒康威定律注定要失败。
康威定律的最好表述是："任何系统的构成，都反映了设计这个系统的组织结构。"
它的出处是 Melvin Conway 在1968年写的一篇文章。后来，弗雷德·布鲁克斯（Fred Brooks）在著名的《人月神话》（The Mythical Man-Month）引用了这条定律。
Melvin Conway 观察到，软件系统的架构看起来与构建它的开发团队的组织结构非常相似。
最初的描述是，如果一个团队编写一个编译器，那么它将是一个单通道编译器；但是，如果两个团队共同开发，那么它将是一个双通道编译器。这个描述后来被发现，广泛适用于大量系统。
正如我的同事 Chris Ford 对我说的："软件耦合是由人类交流促成的。" 如果我可以轻松与代码作者交谈，那么我就更容易对代码有更深入的了解，因此我的代码更容易耦合到该代码。
应对康威定律的第一步是不要与之抗争。我仍然记得一位技术主管，他刚刚被任命为一个大型新项目的架构师，该项目由分布在世界各地不同城市的六个团队组成。"我做出了第一个架构决定"，他告诉我："就是这个系统将有六个主要的子系统。我不知道它们会是什么子系统，但肯定会有六个。"
为了适应康威定律，现在有一种策略，就是一旦定下软件架构，就相应改变组织结构，让紧密耦合模块的开发者更容易沟通。
几乎所有我喜欢的软件架构师，都认同康威定律（Conway Law），认为这个定律非常重要，足以影响到所有系统。而且，你没法与之抗争，想要抗拒康威定律注定要失败。
康威定律的最好表述是："任何系统的构成，都反映了设计这个系统的组织结构。"
它的出处是 Melvin Conway 在1968年写的一篇文章。后来，弗雷德·布鲁克斯（Fred Brooks）在著名的《人月神话》（The Mythical Man-Month）引用了这条定律。
Melvin Conway 观察到，软件系统的架构看起来与构建它的开发团队的组织结构非常相似。
最初的描述是，如果一个团队编写一个编译器，那么它将是一个单通道编译器；但是，如果两个团队共同开发，那么它将是一个双通道编译器。这个描述后来被发现，广泛适用于大量系统。
正如我的同事 Chris Ford 对我说的："软件耦合是由人类交流促成的。" 如果我可以轻松与代码作者交谈，那么我就更容易对代码有更深入的了解，因此我的代码更容易耦合到该代码。
应对康威定律的第一步是不要与之抗争。我仍然记得一位技术主管，他刚刚被任命为一个大型新项目的架构师，该项目由分布在世界各地不同城市的六个团队组成。"我做出了第一个架构决定"，他告诉我："就是这个系统将有六个主要的子系统。我不知道它们会是什么子系统，但肯定会有六个。"
为了适应康威定律，现在有一种策略，就是一旦定下软件架构，就相应改变组织结构，让紧密耦合模块的开发者更容易沟通。