康威定律Conway's law 20190710

Posted 2021-04-24 扯闲大号

"阅读本文大概需要4分钟，速度仅需2分钟"

1967年，马尔文康威(Melvin E Conway)提出了一条著名的【康威定律】:“设计系统架构受制于产生这些设计的组织的沟通结构”。

康威定律著名在不仅仅是应用在系统架构设计上的理论，定律基础，也广泛的运用在公司和(或)企业的组织架构设计，以及社交网络的沟通交流模型。

近几年，微服务架构变得非常活和流行，很多人开始注重了系统架构设计，着重考虑系统架构组件及技术架构选型等问题。好像大多数人听说康威定律，也是多数是因为微服务架构。

微服务架构设计和SOA(面向服务软件体系架构)是相似的，区别在微服务设计抛弃了(不再强调)SOA架构内非常重的ESB企业服务总线，整个业务系统里面的每个单个业务系统内部完全彻底的实现真正的组件化和服务化。作为一个不会技术、写代码、也不会数据库的完全的PPT架构思想的产品，不再赘述架构设计和系统设计。

   

康威定律第一条

communication dictates design.

沟通交流决定了设计。

A systems design is a copy of the organization’s communication structure.

一个系统的设计是完全复制了组织的沟通交流的结构。

   

康威定律第二条

there is never enough time to do something right，but there is always enough time to do it over.

花很多时间也不可能把一件事情做的很完美，但是你花足够的时间就可以做完一件事。

适当的忽略细节，不要做到尽善尽美，先抓主要矛盾，先把主线任务给做好，做的极致;

弹性安全，确保发现问题及时准确，系统能自动恢复复原;

持续集成和用敏捷开发;

分布式系统弹性设计、高可用设计(high availability).

   

康威定律第三条

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

线性系统和线性组织设计之间有潜在的异质同态特性。

根据自己想要什么样的系统，就会去搭建什么样的团队。

需要定义清楚边界和接口，能够自洽，全栈设计，没有整合就是整合。(inter-operate，not integrate)

   

康威定律第四条

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

大的系统结构在开发的过程中，总会向更小的小系统分解分散组织。

一个公司或企业(组织)里面有多少人，就可以计算出来在这个组织里面的沟通成本是多少？

n="代表的quantity变量人"c="代表的是变量沟通成本"c=n（n-1）*2

当系统或组织里面的人增多的时候，沟通成本和维护成本都是成指数级增长的。所以越大的组织，沟通成本就会越高。所以大的组织，通常都会分而治之(divide and conquer)。

系统架构设计的三架马车是保障整个应用、服务等相关产品的高可用性、高扩展性及高并发的。需要通过进行服务器部署来实现架构方案的落地，操作系统、数据库、日志、缓存、熔断及索引的构建，保障业务的输入输出、处理运行。

---

题图:by selective photo of gray shark 726478 from pexels

---

20190711 札记

7月10号五点左右，翻看python爬虫框架scrapy代码的bug开始有些懈怠了，开始慢慢怀疑自己是否真的适合写代码，或者是是否拥有创造性的？毕竟代码都是照着教程里面的一行行敲击下来的，实际的原理和结果似乎都是不是很懂很明白。

随意翻阅电脑网的思维导图，发现了康威定律的图，似乎并不是很完整。之前收藏的几篇关于康威定律的网页也都不见了，又重新搜索找寻出来，加入到网页的书签里面。重新根据自己的理解及Google translate的翻译，重新翻译了一下，之前写的关于原文的理解。再结合之前的经历，随手就把这段文字给敲击下来了。很是粗糙的文字，也花费了大概一个小时的时间。主要是确实这些比较大而全，很基础的，通识的原理理论真的不是那么容易懂。就当时一个启示吧。希望能够坚持把python爬虫精进的最后两课在这周搞定。