概念-法律、原则、心理模型、认知偏差

要投稿，请单击Readme.md，然后单击铅笔图标。进行更改，然后单击“建议文件更改”按钮提交拉式请求。一定要遵循投稿指南。

Amdahl定律是一个公式，它显示了通过增加系统资源可以实现的计算任务的潜在加速比。通常在并行计算中使用，它可以预测增加处理器数量的实际好处，但这受到程序并行性的限制。

最好用一个例子来说明。如果一个程序由两个部分组成，A部分必须由单个处理器执行，B部分可以并行，那么我们可以看到，向执行该程序的系统添加多个处理器只能带来有限的好处。它可能会极大地提高B部分的速度-但A部分的速度将保持不变。

可以看出，即使是50%可并行性的程序在超过10个处理单元的情况下也获益甚微，而95%可并行性的程序仍然可以在超过1000个处理单元的情况下实现显著的速度改进。

随着摩尔定律的减慢，以及单个处理器速度的加速减慢，并行化是提高性能的关键。图形编程就是一个很好的例子-使用基于着色器的现代计算，可以并行渲染单个像素或碎片-这就是为什么现代图形卡通常具有数千个处理核心(GPU或着色器单元)的原因。

破窗理论认为，明显的犯罪迹象(或缺乏对环境的保护)会导致进一步的、更严重的犯罪(或环境的进一步恶化)。

这一理论已经被应用到软件开发中，它表明质量差的代码(或技术债务)会导致一种看法，即改进质量的努力可能会被忽视或低估，从而导致更低质量的代码。随着时间的推移，这种效应会导致质量大幅下降。

这条法律表明，在许多情况下，试图通过增加人员来加速已经迟到的项目的交付，会使交付更晚。布鲁克斯很清楚，这是过于简单化的，然而，一般的推理是，考虑到新资源的启动时间和通信开销，在直接的短期内速度会下降。此外，许多任务可能是不可分的，即很容易在更多资源之间分配，这意味着潜在的速度增长也较低。

“九个女人不能在一个月内生孩子”这句俗语与布鲁克斯定律有关，特别是，有些工作是不可分割或不可平行的。这句话的意思是：“九个女人不能在一个月内生孩子。”这句话与布鲁克斯定律有关。这句话的意思是：“九个女人不能在一个月内生孩子。”

这条法律表明，系统的技术边界将反映组织的结构。当考虑到组织的改进时，通常会提到这一点。康威定律表明，如果一个组织被组织成许多小的、互不相连的单元，那么它生产的软件将是。如果一个组织更多地围绕以功能或服务为导向的垂直领域建立，那么软件系统也会反映这一点。

在互联网上获得正确答案的最好方法不是问问题，而是发布错误的答案。

据史蒂文·麦吉迪(Steven McGeady)说，沃德·坎宁安(Ward Cunningham)在20世纪80年代初建议他：在互联网上获得正确答案的最好方法是不问问题，而是发布错误的答案。麦吉迪称这是坎宁安定律，尽管坎宁安否认其所有权，称其为错误引用。尽管最初指的是Usenet上的互动，但这条定律已经被用来描述其他网络上的互动。

邓巴的数字是一个建议的认知极限，即一个人可以与之保持稳定的社会关系的人数。在这种关系中，一个人知道每个人是谁，每个人与其他人的关系是如何的。对于确切的数字，人们存在一些分歧。#34；……。[邓巴]提出人类只能轻松地维持150段稳定的关系。他把这个数字放在更具社交意义的背景下，如果你在酒吧碰见不速之客，你不会觉得难堪的人数。对这个数字的估计一般在100到250之间。

就像个人之间的稳定关系一样，开发人员与代码库的关系也需要努力维持。当面对大型、复杂的项目，或者拥有许多项目时，我们依靠惯例、政策和模型化的过程来进行规模调整。邓巴的数字不仅在办公室发展时牢记在心，而且在设定团队努力的范围或决定系统何时应该投资于工具以帮助建模和自动化后勤管理时也是如此。将该数字放入工程环境中，它是您有信心加入待命轮换以支持的项目数(或单个项目的标准化复杂性)。

一个工作的复杂系统总是被发现是从一个工作的简单系统演变而来的。一个从零开始设计的复杂系统永远不会工作，也不能通过修补来使其工作。你必须从一个工作简单的系统开始。

盖尔定律暗示，设计高度复杂的系统的尝试很可能失败。高度复杂的系统很少一蹴而就，而是从更简单的系统演变而来的。

万维网就是一个典型的例子。在它目前的状态下，它是一个高度复杂的系统。然而，它最初被定义为在学术机构之间共享内容的一种简单方式。它在实现这些目标方面非常成功，并且随着时间的推移变得更加复杂。

任何观察到的统计规律性一旦出于控制目的而施加压力，就会趋于崩溃。

法律规定，测量驱动的优化可能会导致测量结果本身的贬值。过度选择的措施集(KPI)盲目地应用于一个过程会导致扭曲的效果。人们倾向于通过博弈系统进行局部优化，以满足特定的衡量标准，而不是关注他们行为的整体结果。

无断言测试满足代码覆盖率预期，尽管度量意图是创建经过良好测试的软件。

由提交的行数表示的开发人员性能分数会导致代码库过度膨胀。

这一原则表明，导致负面结果的行为不是恶意的结果。相反，负面结果更有可能归因于这些行动和/或影响没有得到充分了解。

即使考虑到霍夫斯塔特定律，它的时间也总是比你预期的要长。

在查看某件事需要多长时间的估计时，您可能会听到这条定律。在软件开发中，我们往往不太擅长准确地估计需要多长时间才能交付，这似乎是一个不言而喻的道理。

这一定律表明，对一个系统的改进将导致其他部分的恶化，或者它将隐藏其他恶化，导致从目前的系统状态到整体的退化。

例如，特定端点响应延迟的减少可能会导致请求流中进一步增加的吞吐量和容量问题，从而影响完全不同的子系统。

我们倾向于高估一项技术在短期内的效果，而低估其长期效果。

炒作周期是技术随着时间的推移而激动人心和发展的直观表现，最初由Gartner制作。它最好用视觉效果来显示：

简而言之，这个循环表明，人们通常会对新技术及其潜在影响感到兴奋。团队通常很快就会投入到这些技术中，有时会发现自己对结果感到失望。这可能是因为技术还不够成熟，或者现实世界的应用还没有完全实现。经过一段时间后，技术的能力增加了，使用它的实际机会也增加了，团队最终可以变得富有成效。罗伊·阿马拉(Roy Amara)的话最简洁地总结了这一点--我们往往高估了一项技术在短期内的效果，而低估了长期的影响。

有了足够数量的API用户，您在合同中承诺什么都无关紧要：您系统的所有可观察到的行为都将依赖于某个人。

Hyrum的法律规定，当你有足够多的API消费者时，API的所有行为(即使是那些没有被定义为公共合同一部分的行为)最终都将变得依赖于某人。一个微不足道的例子可能是非功能元素，如API的响应时间。一个更微妙的例子可能是依赖于对错误消息应用正则表达式来确定API错误类型的消费者。即使API的公共契约没有说明消息的内容，指示用户应该使用相关的错误代码，一些用户可能会使用该消息，并且更改该消息实质上会破坏这些用户的API。

调试比一开始编写代码要难一倍。因此，如果您尽可能巧妙地编写代码，根据定义，您就没有足够的智能来调试它。

科尼根定律是以布莱恩·科尼根的名字命名的，引述自科尼根和普劳格合著的“编程风格的元素”(The Elements Of Programming Style)一书中的一句话：

每个人都知道，调试一开始就比编写程序难一倍。那么，如果你在写它的时候尽可能聪明，你将如何调试它呢？

虽然夸张，但科尼根定律提出的论点是，简单的代码比复杂的代码更受欢迎，因为调试复杂代码中出现的任何问题都可能代价高昂，甚至是不可行的。

在网络理论中，系统的价值大约与系统用户数量的平方成正比。

这一定律是基于一个系统内可能的两两连接的数量，并且与里德定律密切相关。Odlyzko和其他人争辩说，里德定律和梅特卡夫定律都夸大了系统的价值，因为它们没有考虑到人类认知对网络效应的限制；参见邓巴的数字。

摩尔的预测经常被用来说明半导体和芯片技术进步的绝对速度，事实证明，从20世纪70年代到21世纪末，摩尔的预测非常准确。最近几年，这一趋势略有改变，部分原因是部件可以小型化的程度受到物理限制。然而，并行化的进步，以及半导体技术和量子计算的潜在革命性变化，可能意味着摩尔定律可能在未来几十年内继续适用。

与爱德华·A·墨菲(Edward A.Murphy)相关的是，JR·墨菲定律指出，如果一件事可能出错，它就会出错。

这是开发人员中的一句常见格言。有时，在开发、测试甚至在生产中都会发生意想不到的事情。这也可能与(英式英语中更常见的)“索德定律”(Sod'；‘s Law)有关：

这些法律通常用在滑稽的意义上。然而，确认偏差和选择偏差等现象可能会导致人们过度强调这些规律(大多数情况下，当事情奏效时，它们不会被注意到，然而，失败更容易引起人们的注意，并引发更多讨论)。

奥卡姆的剃须刀表示，在几种可能的解决方案中，最有可能的解决方案是概念和假设数量最少的那个。这个解决方案是最简单的，并且只解决了给定的问题，没有引入意外的复杂性和可能的负面后果。

如果你有两个相互竞争的假设(两个证据都支持的假设)，你会使用假设较少的那个。部分原因是假设较少的模型将更容易使用，并导致更容易理解的模型。但更主要的原因是，假设越少，证伪就越容易。

在最初的上下文中，这部法律是以对官僚机构的研究为基础的。它可能被悲观地应用于软件开发活动，其理论是团队在截止日期临近之前效率低下，然后在截止日期前匆忙完成工作，从而使实际截止日期有点武断。

如果这一定律与霍夫施塔特定律结合起来，就会得出一个更加悲观的观点--工作将会扩大，以填补完成它所需的时间，但仍需要比预期更长的时间。

在Donald Knuth的论文“结构化编程与Go To语句”中，他写道：程序员浪费了大量的时间去思考或担心程序中非关键部分的速度，当考虑到调试和维护时，这些提高效率的尝试实际上会产生很大的负面影响。我们应该忘记小效率，比方说97%的时间：过早优化是万恶之源。然而，我们不应该在这关键的3%中错过我们的机会。

然而，过早优化可以被定义为在我们知道需要之前进行优化(负载较小的术语)。

技术由两类人主导，一类人了解他们没有管理的东西，另一类人管理他们不懂的东西。

这些声明表明，由于不同的选择标准和团队组织方式的趋势，技术组织的工作层面将有一些熟练的人员，而担任管理职务的一些人没有意识到他们正在管理的工作的复杂性和挑战。这可能是由于彼得原理或呆伯特原理等现象造成的。

然而，应该强调的是，这样的法律是概括性的，可能适用于某些类型的组织，而不适用于其他类型的组织。

大型网络(尤其是社交网络)的效用随着网络的规模呈指数级增长。

这个定律是以图论为基础的，其中效用随可能的子群的数量而变化，这比参与者的数量或可能的两两连接的数量要快。奥德利兹科和其他人争辩说，里德定律夸大了系统的效用，没有考虑到人类认知对网络效应的限制；参见邓巴的数字。

这条定律表明，系统中有一定的复杂性是不能降低的。

系统中的一些复杂性是不经意的。这是由于结构不佳、错误或只是要解决的问题建模不当造成的。可以降低(或消除)无意中的复杂性。然而，一些复杂性是固有的，因为问题本身就是复杂的。这种复杂性可以移动，但不能消除。

这条定律的一个有趣之处在于，有人建议，即使简化了整个系统，内在的复杂性也没有降低，而是转移到了用户身上，用户必须以更复杂的方式行事。

这条法律规定，抽象通常用于计算以简化复杂系统的工作，但在某些情况下会泄漏底层系统的元素，这使得抽象以一种意想不到的方式运行。

加载文件并读取其内容可能是一个示例。文件系统API是较低级别内核系统的抽象，其本身是与更改磁盘(或SSD的闪存)上的数据相关的物理进程的抽象。在大多数情况下，将文件视为二进制数据流的抽象将起作用。但是，对于磁性驱动器，顺序读取数据将明显快于随机访问(由于页面错误的开销增加)，但对于SSD驱动器，将不会出现此开销。为了处理这种情况(例如，数据库索引文件被结构化以减少随机访问的开销)，开发人员可能需要知道抽象泄露的实现细节，因此需要了解底层细节才能处理这种情况(例如，数据库索引文件是结构化的，以减少随机访问的开销)。

当引入更多抽象时，上面的示例可能会变得更加复杂。Linux操作系统允许通过网络访问文件，但在本地表示为普通文件。如果出现网络故障，此抽象将泄漏。如果开发人员将这些文件视为普通文件，而没有考虑到它们可能会受到网络延迟和故障的影响，则解决方案将是有缺陷的。

这篇描述法律的文章表明，过度依赖抽象，再加上对潜在过程的理解不足，实际上在某些情况下会使处理手头的问题变得更加复杂。

Photoshop慢启动-这是我过去遇到的问题。Photoshop的启动速度会很慢，有时需要几分钟的时间。问题似乎是在启动时，它会读取有关当前默认打印机的一些信息。但是，如果打印机实际上是网络打印机，这可能需要极长时间。呈现给系统的网络打印机的抽象类似于本地打印机，这给连接性较差的用户带来了问题。

这条法律表明，团体会把更多的时间和注意力放在琐碎或表面上的问题上，而不是严重和实质性的问题上。

常见的虚构例子是一个委员会批准核电站的计划，他们花了大部分时间讨论自行车棚的结构，而不是发电厂本身的更重要的设计。在没有高度的主题专业知识或准备的情况下，很难在关于非常大的、复杂的主题的讨论中提供有价值的意见。然而，人们希望被视为贡献了宝贵的投入。因此，人们倾向于将过多的时间集中在细小的细节上，这些细节可以很容易地进行推理，但不一定特别重要。

上面这个虚构的例子导致了术语“自行车脱皮”(Bike Shedding)的使用，用来表示在琐碎的细节上浪费时间。一个相关的术语是牦牛剃须，它暗含着一项看似不相干的活动，它是主要任务的一系列先决条件中的一部分。

Unix的理念是软件组件应该很小，并且专注于做好一件特定的事情。这可以通过将小的、简单的、定义良好的单元组合在一起，而不是使用大型、复杂、多用途的程序来更容易地构建系统。

像微服务体系结构这样的现代实践可以被认为是这条法律的应用，服务很小，集中在一起，做一件特定的事情，允许复杂的行为由简单的构件组成。

Spotify模式是一种团队和组织结构的方法，已经被Spotify推广。在这个模型中，团队是围绕功能而不是技术来组织的。

Spotify模型还普及了部落、行会、分会的概念，这些都是其组织结构的其他组成部分。

在任何语言设计中，讨论此列表中的一个功能所花费的总时间与该功能所处位置的两次提升成正比。

(简而言之，每花一个小时在语义上，就会花8个小时在注释的语法上)。

与琐碎定律相似，瓦德勒定律指出，当设计一门语言时，花在语言结构上的时间是。

.