程序员与他的康威定律

随手翻了一下压在桌子底下的《人月神话》，发现 Brooks Law 在人月神话中提到了「康威定律」，虽然随着云原生的发展微服务架构已经乏善可陈，但是还是想借助这篇文章来研究一下康威定律给程序员个体带来的思考和启发。

什么是康威定律

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

康威定律（Conway's Law）—— 系统设计出来的结构总是会模仿组织沟通结构的形态。它是由梅尔文·康威（Melvin E. Conway）提出的一种观察结果，表述了组织结构对系统设计的影响。

这句话的核心意义在于，一个组织中的沟通模式、团队结构、以及个体间的协作方式等都会直接或间接地反映在它所设计和构建的软件或系统的架构上。换句话说，如果一个公司的结构是分散的，那么它生产的软件也可能会是由许多相对独立的模块组成；如果一个公司的结构是高度集中的，它生产的软件可能会有一个统一的核心，周围是一些紧密相关的组件。结合下面这张图以及平时接触到的各家公司的产品，是不是能感受到这其中的不同：

康威定律的影响和应用主要体现在以下几个方面：

• 软件架构设计：康威定律意味着在设计软件架构时，必须考虑组织的沟通结构，以确保软件架构能够有效地支持组织中的工作流程和沟通模式。
• 团队组织：软件开发团队的组织结构应该反映和支持其所负责开发的软件模块的结构。例如，服务于同一软件组件的开发人员可能需要更紧密的沟通和协作。
• 协作与沟通：改善跨团队的沟通可以促进不同组件之间更好的集成与协作，从而提高整个系统的质量和效率。
• 组织变革：当组织结构发生变化时，现有的软件架构可能不再合适。这时，组织需要评估现有软件是否需要重构，以适应新的组织结构和工作流程。

第一定律

Communication dictates design

组织沟通方式会通过系统设计表达出来

沟通的问题，会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。

第二定律

There is never enough time to do something right, but there is always enough time to do it over

时间再多一件事情也不可能做得完美，但总有时间做完一件事情

一口气吃不成胖子，先搞定能搞定的。

第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization

线型系统和线型组织架构间潜在的异质同态特性

将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本也就能减低。

第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems

大的系统组织总是比小系统更倾向于分解

当我们面对复杂系统时往往只能通过增加人力来解决，这时一般的解决方法是分而治之（Divide and conquer），所以一个大的组织因为沟通成本/管理问题，总为被拆分成一个个小团队，一个复杂的系统也同样适用。

为什么会有康威定律

康威定律并不是真正的「定律」，而是提出者根据其观察提炼的经验法则，这些经验法则恰好能够解释系统结构和组织之间关系，并且能够帮助程序员和管理者进行优化：

• 指导系统设计：康威定律提醒我们，系统的结构受到设计它的组织结构的影响，因此在设计系统时需要考虑到组织结构对系统的影响，尽可能地将组织结构与系统结构相匹配，以便更好地管理和维护系统。
• 优化组织结构：康威定律也提醒我们，系统结构与组织结构之间的匹配是双向的，优化组织结构可以促进系统设计的优化。因此，我们可以根据康威定律的启示，优化组织结构，以期提高系统的质量和效率。
• 增强团队合作：康威定律认为，系统的结构受到组织结构的影响，这意味着团队之间的沟通和协作至关重要。为了提高系统的质量和效率，团队之间需要建立良好的沟通和合作机制，以便有效地交换信息和协调工作。

怎么应用康威定律

• 模块化设计：在设计系统时，将系统分成相互独立的模块，并将每个模块分配给适当的团队。这样可以减少不同团队之间的依赖和交流，使团队更专注于自己的工作。
• 明确接口和职责：在模块化设计的基础上，为每个模块定义清晰的接口和职责，并确保模块之间的接口相互独立和互通。这可以帮助团队更好地理解自己的职责和作用，并减少团队之间的不必要的依赖和冲突。
• 定期协作和交流：虽然模块化设计可以减少团队之间的交流和依赖，但团队之间的协作和交流仍然是至关重要的。定期召开会议或者通过在线沟通工具交流，可以促进团队之间的理解和协调。
• 优化组织结构：组织结构的优化可以更好地匹配系统的结构，提高团队的协作效率。例如，可以根据不同团队的技能和职能划分团队，或者根据项目的特点划分团队。这样可以更好地匹配系统的结构，提高团队的效率和质量。
• 定期评估和调整：由于团队和组织结构可能会发生变化，因此需要定期评估和调整系统的结构和组织结构。这可以帮助系统保持与组织结构的匹配，并提高系统的质量和效率。

康威定律给个体程序员的启发

理解系统架构演进

程序员应意识到其所在组织的结构和沟通方式会直接影响软件的设计和最终形态。理解这一点有助于程序员在编码前更全面地考虑如何设计模块和接口，以适应组织的沟通模式。

架构设计

康威定律提醒程序员在设计软件时应考虑团队的结构和沟通路径。程序员进行架构设计时需要设计更加模块化和解耦的系统以反映和支持组织的高效运作。

除此之外，还有一个运用康威定律的方法 —— 逆康威定律：根据想得到的软件架构来设计团队结构而不是盲从一个被设计好的团队结构。

改善沟通和效率

康威定律鼓励程序员在团队内部建立有效的沟通机制。良好的内部沟通可以促进信息的流动，降低因误解或信息滞后造成的错误，从而提高项目的整体质量和效率。

从康威定律中吸取的洞见可以帮助程序员优化个人及团队的工作流程，通过改善沟通结构降低冗余和提升协作效率。

References

1. 每个架构师都应该研究下康威定律
2. 微服务基础 - 康威定律
3. 结构优于制度，软件开发中的康威定律
4. Flattening Hierarchies Through Enterprise Social Networking | The TIBCO Blog
5. Conway's Law vs. Inverse Conway's Law and the future of build vs. buy in martech - Chief Marketing Technologist
6. Inverse-Conway-Maneuver: How to speed up product development teams successfully | Thoughtworks