康威定律

”设计系统的架构受制于产生这些设计的组织的沟通架构“

                                             --马尔文·康威

 

参考文献：http://www.melconway.com/Home/Conways_Law.html

　　　　　https://wuchenxu.com/2016/11/20/Conways-law/

　　　　　https://yq.aliyun.com/articles/8611

 

康威的原文中提出的各定律：

　　第一定律：组织沟通方式会通过系统设计表达出来。

　　第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。

　　第三定律：线型系统和线型组织架构间有潜在的异质同态特性。

　　第四定律：大的系统组织总是比小系统更倾向于分解。

　　　　　　　　　　　　　　　　　　　　--wiki

康威定律的结论：

　　Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.
This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.
Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.

 

论文主要观点：

 

　　系统的结构受限于设计这个系统的组织的沟通结构。由于系统的结构可能会随着设计的深入而变化，所以必须保持设计组织结构的精简与灵活。

变体：

　　The organization of the software and the organization of the software team will be congruent.

　　软件本身的组织结构与软件团队的组织结构是一致的。

　　

　　If the parts of an organization (e.g. teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble… Therefore: Make sure the organization is compatible with the product architecture”.

　　如果组织（团队、部门、或者分支部门）的组成部分不能正确的与产品的必要组成部门相对应，或者组织之间的关系不能反应产品组成部分之间的关系，那么这个项目就会有麻烦，所以必须保证组织与产品架构的兼容。

　　

　　The structure of a problem reflects the structure of the organization that created it.

　　问题的结构反应了产生问题的组织的结构。

 

康威定律如何解释微服务的合理性　　

了解了康威定律是什么，再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。

• 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理
• 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
• 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效
• 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的

带来的具体的实践建议是：

• 我们要用一切手段提升沟通效率，比如slack，github，wiki。能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。
• 通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。
• 你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。
• 做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的Bezos有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7，8人左右（包含前后端测试交互用研等，可能身兼数职）。

再对应下衡量微服务的标准，我们很容易会发现他们之间的密切关系：

• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 做有生命的产品而不是项目
• Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）
• 自动化运维（DevOps）
• 容错
• 快速演化

转载于:https://www.cnblogs.com/richered/p/11451373.html