🎥 🚠 🤳🏾 编程法则 🖊️ 💎 👵🏾

对开发人员有用的法律，理论，原则和模式

介绍

仓库翻译github.com/dwmkerr/hacker-laws

在与软件开发有关的讨论中，人们经常谈论不同的法律。该存储库存储其中一些最著名的链接和描述。

它包含对某些法律，原则和法律的解释，但并不鼓动它们。是否使用它们始终是一个争论点，这完全取决于您的工作。

法律

阿姆达尔定律

阿姆达尔定律是一个公式，它证明了加速计算任务的潜力，而这可以通过增加系统资源量来实现。它通常用于并行计算中，并且考虑到程序的并行性限制，可以预测增加处理器数量的真正好处。

我们举一个例子。如果程序由两部分组成-必须在一个处理器上执行的A部分和可以并行执行的B部分，很明显，将多个处理器添加到执行该程序的系统中的优势是有限的。潜在地，这可以极大地加速B部分-但是A部分的速度不会改变。

下图显示了可能提高速度的示例：

如您所见，即使可以并行执行程序的50％，添加10个以上独立处理器的好处也可以忽略不计。如果程序可以并行化95％，那么即使添加了数千个处理器，这些改进也将是显而易见的。

随着摩尔定律的放慢和处理器的加速，并行化成为提高效率的关键。图形编程是一个很好的例子-基于着色器的现代编程允许您并行绘制图像片段，因此在现代图形卡中，您可以找到数千个处理器核心（GPU或着色器模块）。

破窗理论

破窗理论声称，犯罪的明显迹象（或对环境的关注不足）导致犯罪的数量和严重性增加（环境进一步恶化）。

该理论已被应用到软件开发中，这表明不良的代码质量（或所谓的“ 技术债务 ”）可能会导致人们感觉到所有提高质量的尝试都会被忽略或低估，从而导致出现新的不良代码。这种效果是级联发展的，这就是为什么质量会随着时间而下降的原因。

布鲁克斯法

为一个较晚的项目增加更多的人力资源会进一步延迟其产出。

布鲁克斯法则说，在许多情况下，试图通过增加其他人员来加快已经发布的项目的发布速度，导致了该项目的发布甚至比发布的时间晚。但是，布鲁克斯强调，这是问题的过分简化。他的理由如下：考虑到调试新资源所需的时间成本以及人与人之间的沟通，在短期内项目的开发速度会下降。同样，许多任务可能不会分离，也就是说，它们无法轻易地在资源数量之间增加，资源数量已经增加，因此潜在的速度提升并不是那么重要。

俗语“九名妇女一个月内无法生孩子”是布鲁克斯法则，特别是因为某些类型的工作无法分割或平行化。

这是《神话人月》一书的主题。

康威法

康韦（Conway）的法律规定，设计系统的技术限制将反映组织的结构。当试图改善组织时，经常会想起他。法律说，如果一个组织由许多小的，不相关的模块组成，那么它创建的程序将是相同的。如果组织将基于某些功能或服务围绕垂直行业构建，则其软件将反映这一事实。

坎宁安法

在Internet上找到正确答案的最佳方法不是提出问题，而是发布故意的错误答案。

斯蒂芬·麦克吉迪（Stephen McGeady）说，在1980年代初，沃德·坎宁安（Ward Cunningham）给了他建议：“在互联网上找到正确答案的最佳方法不是提出问题，而是故意发布错误答案。” 麦克吉迪称其为“坎宁安法则”，尽管坎宁安本人否认这一说法，并称他“引用不正确”。尽管该词最初指的是Usenet上的交流，但自那以后该法律就被用来描述工作和其他社区（维基百科，Reddit，Twitter，Facebook）。

邓巴号

邓巴（Dunbar）的数量是一个人可以维持的永久性社会纽带的数量的限制。这是指涉及对特定个体的鲜明特征的了解，必须保持的联系，他的性格，他的社会地位以及他与其他人的联系的关系。

此类关系的确切数量未知。邓巴本人建议，一个人可以舒适地支持不超过150个这样的联系。他在一个更加社交化的环境中描述了这一点：“如果您不小心在酒吧碰到他们，那么您会毫不犹豫地加入而没有邀请喝酒的人数。”通常，此数字的估计值从100到250不等。

就像人与人之间的稳定关系一样，维持程序员与代码的关系也需要大量的精力。当面对大型复杂项目或许多小型项目的所有权时，我们依赖某些协议，政策和程序。重要的是，不仅要在增加员工人数时考虑邓巴号，而且在确定团队规模时或系统应获取用于建模和自动化物流的辅助工具时，都应考虑邓巴号。在工程环境中，这是您可以确定地将其包含在代码支持组中的项目数（或一个项目的标准化复杂度）。

哥尔定律

工作复杂的系统必然来自工作简单的系统。从头开始设计的复杂系统永远无法工作，并且无法对其进行修复以使其正常工作。您需要从一个简单的操作系统开始。

戈尔定律表明，开发非常复杂的系统的尝试很可能会失败。高复杂度的系统很少是一次创建的-它们是从简单的系统演变而来的。

一个典型的例子是全球网络。在当前状态下，它是一个高度复杂的系统。但是，最初被认为是在机构之间交换内容的简单方法。她非常成功地完成了这些目标，并且不断发展，随着时间的推移，她变得更加复杂。

古德哈特定律

一旦对其施加压力进行控制，任何观察到的统计模式都趋于崩溃。

它通常也被表述为：

当一项措施成为目标时，它就不再是一项好的措施。
玛丽莲·斯特林（Marilyn Strain）

法律规定，基于某些措施的优化可能会导致这些措施的折旧。盲目地应用于过程的过度选择性测量（KPI）会导致失真。人们努力在本地优化流程，“欺骗”系统以满足特定指标，而不是关注行动的整体结果。

例子：

尽管创建了这样的度量标准以便对程序进行了良好的测试，但没有声明的测试满足了对代码覆盖率的期望。
根据为项目贡献的行数来评估开发人员的有效性，会导致代码不合理地膨胀。

汉隆剃刀

切勿将恶意归因于愚蠢完全解释的内容。

该原则指出，导致负面结果的行动不能有恶意。负面结果更有可能是由于这些行为及其后果尚未得到很好的理解。

霍夫斯塔德定律

即使您考虑了霍夫斯塔德定律，完成任务的时间总是比您预期的要多。

在估算项目花费的时间时，您可能会遇到对该法律的引用。在软件开发领域，我们不太可能准确地估计完成项目所花费的时间，这是不言而喻的。

摘自《哥德尔，埃舍尔，巴赫：这无尽的花环》这本书。

休伯定律

改善等同于破坏。

该法律规定，对系统某一部分的改进会导致其他部分的破坏，或者隐藏其他类型的破坏，与当前状态相比，这通常会导致系统性能下降。

例如，减少系统某些部分中的响应时间可能导致其吞吐量增加，结果，导致请求流路径中某处的容量出现问题，这可能会影响另一个子系统。

炒作与阿马尔定律的循环

我们倾向于在短期内高估技术的影响，而在长期内低估技术。

炒作周期是对技术的热情和发展的可视化，最初由Gartner建立。该图最好地说明了这一点：

技术问世后，其普及程度达到了expectations肿的期望的峰值，然后陷入失望的空洞，沿着启蒙的坡度上升，并达到了生产力的平稳期。

简而言之，该周期认为，人们通常会围绕新技术及其潜在后果产生热情。团队通常很快就会沉迷于这些技术，并且对结果常常感到失望。可能是因为该技术尚未得到充分开发，或者尚未考虑其应用方法。经过一段时间后，技术的功能增强，实际应用程序的数量也增加，此后，团队最终可以提高工作效率。

西兰定律

当您拥有足够数量的API用户时，您向每个人承诺的功能都没有关系：对于系统行为的任何可能功能，都会有一个用户依赖于它。

希拉姆法则假设，如果您的API有足够的用户，则将有一个依赖于它的用户来进行系统的任何可能行为（甚至未在公共合同中进行描述）。一个简单的例子是非功能性的API功能，例如响应时间。一个更微妙的例子是消费者，他们依靠将正则表达式函数应用于错误描述来确定错误的类型。即使公共合同未对消息的内容作任何说明，并暗示用户必须使用错误代码，他们中的一些人仍可能决定使用该消息，并且更改消息将破坏这些用户的API。

克尼根法

调试代码比编写代码困难两倍。因此，如果您编写代码时要尽自己的能力，那么就定义而言，您将没有足够的智能来对其进行调试。

Kernigan的定律以Brian Kernigan的名字命名，取自他和Plauger所写的书：“编程风格的要素”。

每个人都知道调试代码比编写代码难两倍。因此，如果您在编写代码时全力以赴，该如何调试它？

尽管该法律过于夸张，但它声称使用简单代码比使用复杂代码更好，因为调试复杂代码中出现的任何问题可能太昂贵，甚至不可能。

梅特卡夫定律

在网络理论中，网络的实用性大约随着其用户数量的平方增长。

该定律基于系统内可能的成对连接的数量，并且与里德定律密切相关。奥德利科（Odlyzhko）等人认为，里德（Reed）和梅特卡夫（Metcalf）的定律夸大了系统的价值，没有考虑到人类理解网络的能力的局限性。参见邓巴号。

摩尔定律

大约每24个月，放置在集成电路芯片上的晶体管数量就会增加一倍。

摩尔的预测经常被用来证明改进半导体和芯片制造技术的惊人速度，它出人意料地准确，并且从1970年代到2000年代后期一直有效。近年来，这种趋势已略有改变，特别是由于部件微型化的物理限制。但是，并行化的进展以及半导体技术和量子计算机的潜在革命性变化可能意味着摩尔定律可能在未来几十年保持不变。

墨菲定律

一切可能出错的地方都会出错。

由爱德华·墨菲（Edward A.

这句话是开发人员经常使用的。有时，在开发，测试甚至生产过程中会发生意想不到的事情。它可以与卑鄙定律相关联，卑鄙定律在英国更常使用[事实上，在俄罗斯也已广为人知。翻译：]：

如果出现问题，将在最坏的情况下发生。

通常，这些“法律”以幽默的方式使用。但是，诸如确认偏差和系统选择错误之类的现象可能导致人们过分热衷于这些定律（在大多数情况下，当一切正常进行时，没有人注意到这一点，但是失败更引人注目并且引起了更多的讨论）。

奥卡姆剃刀

您不应不必要地繁衍。

奥卡姆（Occam）的剃刀声称，在可能的解决方案中，包含最少概念和假设的解决方案最有可能。该解决方案将是最简单的，并且只会解决给定的问题，而不会带来随机的困难和可能的负面后果。

帕金森定律

工作填补了分配给她的时间。

在原始情况下，法律是基于繁文tape节的研究。悲观地说，它可以应用于软件开发，假设团队在项目截止日期开始之前将效率低下，然后急于按时交付，这使得特定的结束日期相当随意。

如果将其与霍夫斯塔德定律结合起来，您将获得更加悲观的观点：工作将不断扩展，直到完成所有所需的时间为止，而且仍然比预期的花费更多。

过早优化的效果

过早的优化是万恶之源。

在Donald Knuth的著作“使用GoTo进行结构化编程”中，他写道：“程序员花费大量时间来思考和担心程序非关键部分的执行速度，如果考虑调试和支持它们，试图使它们变得更有效会产生很大的负面影响。我们需要忘记97％的时间效率不重要：过早的优化是万恶之源。但是，在3％的危急情况下，我们不应错过自己的机会。”

但是，过早优化也可以描述为在了解我们需要做的事情之前对某些事物进行优化的尝试。

帕特法

技术部门由两种类型的人控制：一类了解自己无法控制的人，一类掌握自己不了解的东西。

对于法律而言，帕塔经常得出帕塔结论：

在任何技术层次结构中，能力的转变都会随着时间的推移而发展。

这些陈述表明，由于选择标准和团队组织趋势的不同，在技术组织的工作级别上总是会有一定数量的有经验的人，而在管理级别上总是会有一些人对他们所管理工作的复杂性和问题一无所知。

但是，值得强调的是，此类法律是非常粗略的概括，可能适用于某些类型的组织，而不适用于其他类型的组织。

里德定律

大型网络（尤其是社交网络）的效用随网络规模的增长呈指数增长。

该定律基于图论，其中效用随着可能的子组的数量扩展，其增长速度快于参与者或可能的成对连接的数量。奥德利科（Odlyzhko）等人认为，里德（Reed）和梅特卡夫（Metcalf）的定律夸大了系统的价值，没有考虑到人类理解网络的能力的局限性。参见邓巴号。

复杂性守恒定律（特斯勒定律）

法律规定该系统具有一定的复杂性，无法降低。

系统的部分复杂性可能会意外发生。这是结构不良，错误或无法成功解决问题的建模结果。可以减少或消除无意的复杂性。但是，某些类型的复杂性是任务本身的复杂性的整体结果。这种复杂性可以移动，但不能消除。

该法则有趣的元素之一是这样一个假设，即即使简化了整个系统，其内部复杂性也不会降低，而是落到了行为难度更大的用户身上。

流动抽象定律

所有非平凡的抽象都会受到一定程度的限制。

该法则指出，抽象技术通常在IT中用于简化复杂系统的工作，在某些情况下会泄漏，从而使作为其基础的系统元素向上流动，这就是为什么抽象开始表现出不可预测的行为的原因。

一个示例是下载文件并读取其内容。文件系统API是低级内核系统的抽象，低级内核系统本身是与更改磁板（或SSD闪存）中的数据相关的物理过程的抽象。在大多数情况下，将文件表示为二进制数据流的抽象将起作用。但是，从磁盘顺序读取数据要比随机访问它们快，但是SSD不会出现此类问题。当抽象泄漏了开发人员需要了解的实现细节时，您需要了解深入的细节才能处理这些情况（例如，索引数据库文件的结构可减少随机访问时间）。

添加新的抽象时，以上示例可能会变得更加复杂。 Linux允许您通过网络访问文件，但是在本地可以将它们视为“正常”文件。如果网络出现问题，此抽象将泄漏。如果开发人员将它们视为“正常”，而不考虑它们容易出现延迟和网络故障的事实，那么他的解决方案将是次优且有问题的。

在描述法律的文章中，假定过度沉迷于抽象，加上对基本过程的理解不足，在某些情况下甚至会使解决问题的过程变得复杂。

示例：Photoshop启动缓慢。我遇到了这个问题过去。Photoshop的启动速度非常慢，有时需要几分钟。显然，问题在于启动时它默认读取有关当前打印机的信息。但是，如果此打印机是网络打印机，则可能需要很长时间。网络打印机类似于本地打印机的抽象，在通信不良的情况下引起了用户问题。

琐碎定律

法律规定，与讨论严肃而广泛的问题相比，小组在讨论装饰性或琐碎问题上要花费更多的时间和精力。

通常，一个例子就是批准核电站计划的委员会的工作，该委员会大部分时间都在讨论自行车停放的结构，而不是站本身设计中最重要的问题。没有对这一主题的广泛了解，可能很难为讨论非常大和复杂的主题做出有价值的贡献。但是，人们希望因提出宝贵意见而受到关注。从这里开始趋向于专注于细微的细节，这些细节很容易谈论，但是对于整个项目而言不一定重要。

上面给出的虚拟示例产生了“自行车棚效应”一词，该术语描述了在讨论琐碎细节方面所花费的时间。有一个类似的术语“ y牛理发”，它描述了似乎无关的活动，是一长串必要的准备步骤的一部分。

Unix哲学

Unix的哲学是软件组件应该很小，并专注于做好一项特定任务。通过从小型，简单且定义明确的模块中进行招聘，而不是使用大型，复杂，多功能的程序，从而促进了构建系统的过程。

可以将现代实践（例如“微服务体系结构”）视为这种理念的应用-服务很小，专注于一项特定任务，使您可以从简单的构建块中做出复杂的行为。

Spotify模型

Spotify 提倡的团队结构和组织方法。在此模型中，团队是围绕程序功能而不是技术来组织的。

该模型还提倡部落，行会，分支机构的概念-组织结构的其他组成部分。

沃德定律

在设计任何语言时，花费在讨论此列表中的某个功能上的总时间与该功能在列表中的位置编号的功效成正比。
0.语义学。
1.语法。
2.词法语法。
3.评论的词法语法。

也就是说，在语义上花费的每个小时，在注释语法上花费的时间为8个小时。

与琐碎定律一样，瓦德勒定律假定在设计语言时，与这些结构的重要性相比，花在语言结构上的时间量不成比例地大。

惠顿定律

不要成为山羊。

威尔·惠特安（Will Wheatan）制定的这项简洁，简单和全面的法律旨在在专业组织中增进和谐与尊重。在对代码进行专家评估时，与同事进行对话，寻求对其他观点的异议，批评以及通常在人与人之间的专业交流时，都可以使用它。

原则

原则通常与设计程序的建议相关。

迪尔伯特原理

在公司中，存在将无能的员工升级为经理的趋势，以将其从工作流程中消除。

斯科特·亚当斯（斯科特·亚当斯，斯科特·亚当斯（Dilbert漫画的创造者））提出的管理概念，受到彼得原理的启发。根据迪尔伯特（Dilbert）原则，将那些不能被认为胜任的员工晋升为经理，以限制对公司可能造成的损害。亚当斯于1995年在《华尔街日报》上的一篇文章中首先解释了这一原理，然后在他1996年的著作《迪尔伯特原理》中对其进行了详细描述。

帕累托原理（80/20规则）

在大多数情况下，生活中的一切分布不均。

帕累托原则指出，在某些情况下，投资的一小部分是大部分结果的原因：

80％的程序可以在20％的时间内编写（最困难的20％的程序可以在剩下的80％的时间内完成）。
20％的努力将产生80％的结果。
20％的工作创造了80％的利润。
20％的错误导致80％的程序崩溃。
80％的时间使用20％的功能。

在1940年代，经常被称为质量管理之父的美国罗马尼亚裔工程师约瑟夫·朱兰（Joseph Juran）开始将帕累托原理应用于质量问题。

同样，作为原则80/20，最重要的小法则是要素不足原则。

实例：2002年，微软报告说，修复了20％的最常见错误后，将修复80％的Windows和Office相关问题和崩溃。

彼得原理

在等级制度中，每个人都有上升到自己的无能水平的趋势。

劳伦斯·约翰斯顿·彼得（Lawrence Johnston Peter）提出的管理理念指出，出色的人会得到晋升，直到达到不再应付的水平（“无能水平”）。由于他们足够高地爬升，因此他们已经不太可能被解雇（除非他们制造出某种完全胡说八道的东西），因此他们将保持在这个位置，因为他们在组织中的行为技能不一定会一致，因此他们缺乏必要的技能具有成功担任该职位所需的技能。

对于只从事纯技术角色的工程师，但通常要建立自己的事业以领导其他工程师的管理，这是特别有趣的。这需要一套完全不同的技能。

可靠性原理（Postel定律）

对您的活动要保守一些，对他人的贡献要开放一些。

此原理通常应用于服务器应用程序开发。据他说，您发送给其他人的数据应尽可能小并且要尽可能好以符合标准，但是，如果您要处理这些数据，则您自己必须接受不完全标准化的数据。

该原理的目的是创建可靠的系统，该系统可以消化格式较差的数据，但其含义仍可以理解。但是，接收非标准输入数据可能会导致与安全漏洞相关的后果，尤其是在未对这些数据的接收进行良好测试的情况下。

随着时间的流逝，接收非标准数据的做法可能导致以下事实：协议将停止开发，因为那些实现数据交换的协议将开始依赖程序的自由度，从而创建新功能。

固体

以下5个原则的首字母缩写：

S：单一责任原则
O：开放/封闭原则
L：Liskov替代原则
I：接口隔离原则[ [接口分离原理]
D：依赖倒置原理

这些是面向对象编程的关键原理。这样的设计原则应有助于开发人员创建易于维护的系统。

唯一责任原则

每个对象必须承担一个责任，并且该责任必须完全封装在类中。

SOLID的第一原则。原则指出，每个模块或类只能做一件事。实际上，这意味着程序功能的一个小小的单一更改应该只需要更改一个组件。例如，要更改检查密码复杂性的过程，只需将程序固定在一个地方即可。

从理论上讲，这可以提高代码的可靠性并简化其更改。更改的组件负全责的事实意味着应该更容易测试此更改。从上一个示例更改密码复杂度检查组件仅应影响与密码复杂度相关的功能。谈论具有许多职责的组件更改将影响什么会更加困难。

开放/封闭的原则

实体必须开放才能扩展，而封闭则不能更改。

SOLID的第二个原则。该原则指出，实体（类，模块，函数等）应允许扩展其行为，但不应更改其当前行为。

一个假设的示例：设想一个可以将Markdown标记文档转换为HTML标记文档的模块。如果可以扩展该模块，以便它学习如何处理Markdown格式的新功能，而无需更改其内部功能，则该模块将打开以进行扩展。如果模块无法更改当前Markdown功能的处理，则将模块关闭以进行修改。

该原理与面向对象的编程特别相关，您可以在其中设计易于扩展的对象，但不应设计内部会意外更改的对象。

芭芭拉·李斯科夫（Barbara Liskov）换人原则

应该可以在不破坏系统的情况下用子类型替换类型。

SOLID的第三项原则。该原理指出，如果组件依赖于类型，则应该可以使用该类型的子类型，以便系统不拒绝工作或不需要该子类型的详细信息。

例如，我们有一个从表示文件的结构中读取XML文档的方法。如果该方法使用基本类型文件，则该函数应能够使用该文件中的所有内容。如果文件支持反向搜索，并且XML解析器使用此功能，但是派生类型“网络文件”拒绝使用反向搜索，则“网络文件”违反了这一原理。

该原理与面向对象的编程特别相关，在该模型中，必须非常仔细地对类型层次结构进行建模，以免引起系统用户的困惑。

接口分离原理

软件实体不应依赖于它们不使用的方法。

SOLID的第四项原则。该原则指出，组件的使用者不应依赖于它不使用的组件的功能。

例如，我们有一个从表示文件的结构中读取XML文档的方法。它只需要读取字节，就可以在文件中向前或向后移动。如果由于与文件方法无关的文件结构的更改而必须更新此方法（例如，由于代表文件安全性的访问控制模型的更新），则将违反此原理。对于文件来说，最好实现“可搜索流”接口，并最好使用XML方法。

该原理与面向对象的编程特别相关，在该编程中，使用接口，层次结构和抽象类型来最小化组件之间的连接。该原则要求使用鸭子类型，这是一种消除显式接口的方法。

依赖倒置原则

上级模块不应依赖于下级模块。

SOLID的第五项原则。该原理指出，较高级别的控制组件不应了解其依赖项的实现细节。

例如，我们有一个程序可以从网站读取元数据。大概，其主要组件应该知道下载网页内容的组件和读取元数据的组件。如果我们考虑依赖倒置的原理，那么主要组件将仅依赖于接收字节数据的抽象组件，而它又依赖于能够从字节流中读取元数据的抽象组件。主要组件对TCP / IP，HTTP，HTML等一无所知。

该原理相当复杂，因为它会反转系统中的预期依赖关系。实际上，这还意味着一个单独的控件组件必须保证抽象类型的正确实现（在前面的示例中，必须为组件元数据读取器提供某些东西，以便通过HTTP下载文件并从meta HTML标记读取数据）。

不要重复自己的原则

每条知识在系统中都应具有唯一，一致和权威的表示。

不要重复自己，或者说DRY，它可以帮助开发人员减少代码的可重复性并将信息保存在一个地方。安迪·亨特（Andy Hunt）和戴夫·托马斯（Dave Thomas）于1999年在他们的《实用程序员》一书中提到了这一点。

DRY原理的反义词干]应该是WET的原则湿]-“两次写入所有内容”或“我们喜欢打字” [我们喜欢打字]。

实际上，如果您在两个或多个位置重复了相同的信息，请使用DRY原理，将它们合并到一个位置，然后根据需要重新使用它们。

吻原理

保持简单，愚蠢[别复杂，傻瓜]

KISS原则说，大多数系统只要不复杂就可以更好地工作。因此，简单性应该是开发的主要目标，并且应避免不必要的复杂性。它起源于1960年的美国海军，该词被归因于飞机设计师克拉伦斯·约翰逊（Clarence Johnson）。

最好以约翰逊（Johnson）为一组设计工程师提供一小套工具并指示他们设计飞机的示例为例，以使普通机械师仅使用这套工具就能将其固定在战场上。这里的愚蠢表示事物如何分解与修复工具的复杂性之间的关系，而不是工程师的思维能力。

雅尼

您不需要的缩写[您将不需要]。

仅在确实需要时才执行功能，而不是在以后认为需要时才执行。

极限编程（XP）的作者和《已安装的极限编程》一书的作者罗恩·杰弗里斯（ Ron Jeffries）建议，开发人员应仅实现当前所需的功能，而不是试图预测未来，而是实现以后可能需要的功能。

遵循此原则应减少数据库中未使用的代码量，并浪费时间和精力，而这不会带来任何好处。

分布式计算的误解

也称为网络计算的谬论。这是有关可能导致软件故障的分布式计算的假设列表。这些是以下假设：

网络是可靠的。
延迟为零。
带宽是无限的。
网络是安全的。
拓扑不会更改。
只有一名管理员。
运费为零。
网络是同质的。

1991年Bill Joy和Tom Lyon列出了前四个，而James Gosling首先将它们归类为“网络计算误解”。彼得·德意志（Peter Deutsch）添加了第5，第6和第7错觉。在90年代后期，高斯林（Gosling）排名第八。

一群工程师从当时在Sun Microsystems进行的过程中得到了启发。

在开发可靠的代码时，应仔细考虑这些错误。每个错误都可能导致逻辑错误，无法应付分布式系统的实际情况和复杂性。

编程法则