康威定律(Conway’s Law):软件的结构反映了开发软件的人员组织的结构。
或者说得更清楚一点:组织所设计的系统的结构受限于组织的通信结构。
很多组织是根据功能性技能来划分团队的,所以会有前端开发团队、后端开发团队和数据库开发团队。简单地说,如果某人想要改变的东西属于其他人,那么他就很难改变这些东西。
现在越来越多的组织根据有界上下文来组建团队,而微服务等架构也在根据服务边界而不是孤立的技术架构分区来组建团队。
因此,根据目标软件架构来组建团队可以更容易实现软件架构,而这就是对抗康威法律的一种有效方式。
这个定律说明了系统的技术边界可以反应一个组织的结构,它通常会在改进组织时被提及。康威定律表明,如果一个组织被分散成许多小而无联系的单元,那么它开发的软件也是小而分散的。如果组织是更多地围绕以功能或服务为导向的垂直结构,那么软件系统也会反映这一点。
康威定律 (康威法则 , Conway’s Law) 是马尔文·康威1967年提出的:“设计系统的架构受制于产生这些设计的组织的沟通结构。”
即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。
康威定律源于模块的设计者需要互相之间频繁沟通,而跨部门交流比较难。
埃里克·雷蒙(《大教堂与市集》的作者)在《新黑客词典》中,称康威定律指出了软件架构与软件团队架构的等价(congruent)。例如,“如果你有4个团队在做一个编译器,你会得到一个4遍处理的编译器”。
James O. Coplien与Neil B. Harrison在《敏捷软件开发的组织模式》中写道:
“如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系,那么项目将会遇到麻烦。因此,应该确保组织结构兼容于产品架构。”
康威的原文中提出的各定律:
- 第一定律:组织沟通方式会通过系统设计表达出来
- 第二定律:时间再多一件事情也不可能做的完美,但总有时间做完一件事情
- 第三定律:线型系统和线型组织架构间有潜在的异质同态特性
- 第四定律:大的系统组织总是比小系统更倾向于分解
Eric Hollnagel在2009年的《Efficiency-Effectiveness Trade Offs》一书中类似的论点:
Problem too complicated? Ignore details.
Not enough resources?Give up features.
翻译成中文就是:
问题太复杂?先忽略细节,抓住主要矛盾。
没有足够的资源?放弃一些可有可无的功能特性。
参考
https://cloud.tencent.com/developer/article/1421055?from=article.detail.1525574
https://github.com/nusr/hacker-laws-zh
https://zh.wikipedia.org/wiki/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B