GitHub最热！码代码不得不知的全部定律法则

当谈到开发问题时，人们总会谈论各类定律。但对于大多数人来讲，总有一些是你不了解的，这个问题就须要使用程序员最喜欢的方法解决了：最近 GitHub 上的一个「定律合集」项目忽然登上了趋势榜第二位，Star 数上千，该项目对一些最多见的定律进行了归纳，详情见下文。

选自GitHub，做者：Dave Kerr，机器之心编译。

你们都是资深程序员，之后就不要老念叨「真香定律」了。

• 项目连接：github.com/dwmkerr/hac…

本文包含对一些定律、原则和模式的解释，但并不主张其中任何一项。是否要应用哪一个定律一直是一个争论性问题，而且很大程度上取决于你在作哪方面的工做。

这些规则目录以下：

定律

• 阿姆达尔定律

• 布鲁克斯法则

• 康威定律

• 侯世达定律

• 炒做周期 & 阿玛拉定律

• 海勒姆法则

• 摩尔定律

• 帕金森定律

• Putt's Law

• 复杂性守恒定律（泰斯勒定律）

• 抽象漏洞定律

• 帕金森琐碎定律

• Unix哲学

• The Spotify Model

• Wadler's Law

原则

• 稳健性原则

• SOLID

• 单一功能原则

• 开闭原则

• 里氏替换原则

• 接口隔离原则

• 依赖反转原则

对于以上如此多的定律和原则，咱们选取了其中一些定律和全部的原则进行编译。如今，先简单看一下定律吧↓↓

定律

阿姆达尔定律

维基百科：计算机科学界的经验法则，因吉恩·阿姆达尔而得名。它表明了处理器并行运算以后效率提高的能力。阿姆达尔定律是固定负载（计算总量不变时）时的量化标准。

举例说明，若是一个程序由两部分（A和B）组成，A必须有单个处理器执行，B能够并行执行，那么在执行该程序的系统中增长多个处理器带来的好处是有限的。它可能会大大提高B的速度，但A的速度会保持不变。以下如所示：

从图中能够看出，一个程序若是只有50%的部分可并行处理，那它使用10个以上处理单元时，处理速度将不会有很大的提高。而一个程序若是有95%的部分可并行处理，即便使用的处理单元超过1000个，其处理速度也会显著提升。

侯世达定律

维基百科：作事所花费的时间老是比你预期的要长，即便你的预期中考虑了侯世达定律。

当你估计作一件事要花费多长时间时，可能会想到这必定律。软件开发中的老生常谈是，咱们每每很难估计交付某个东西所须要的准确时间。

炒做周期 & 阿玛拉定律

维基百科：咱们老是高估一项技术的短时间效益，而低估其长期效果。

此定律被描述为鼓励人们思考科技所能带来的长期影响的言论。同时，阿玛拉定律也被人们称为是对“炒做周期”（技术成熟度曲线）最形象的说明。以下图所示：

简言之，这一周期代表，新技术及其潜在影响一般会引发一阵兴奋。而后不少团队快速投入该技术，而后有时会对结果感到失望。这多是由于技术还不够成熟，也多是由于现实应用尚未彻底实现。

通过一段时间后，技术的能力增长，使用技术的实际机会也增长，置身其中的团队最终开始受益。

海勒姆法则

网络定义：当一个 API 有足够多的用户时，你在约定中承诺什么都无所谓，全部在你系统里面被观察到的行为都会被一些用户直接依赖。

海勒姆法则指出，当你的API有很是多的用户时，API中的全部行为最终都会被某我的所依赖。举个简单的例子：非功能性元素，如API的响应时间。稍微复杂一点的例子：依赖对错误消息应用正则表达式来肯定API错误类型的用户。

摩尔定律

该定律认为，集成电路中的晶体管数量大约每两年翻一番。

该定律一般用来表示半导体和芯片技术发展的绝对速度。从上世纪70年代到90年代末，摩尔的预测一直很是精准。但近年来，该趋势已经发生了细微的变化，部分缘由在于组件小型化程度受到的物理限制。然而，并行化的发展以及半导体技术和量子计算领域潜在的革命性变化，可能意味着摩尔定律在将来几十年仍将适用。

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

该定律认为每一个系统内都有必定的复杂性不可减小。

系统中的某些复杂性是“不经意的”。多是由结构不良、错误或只是建模不良形成的结果。这些不经意形成的复杂性是能够减小（或消除）的。可是，有些复杂性是“固有的”，是由亟待解决问题的内在复杂性形成的。而这种复杂性能够移动，但没法消除。

这个定律有趣的一点在于，即便简化整个系统，也没法下降内在的复杂性。这种方法只不过是将复杂性转移到了用户一方，而后用户必须以更复杂的方式行事。

帕金森琐碎定律

该定律认为，大型组织会花费大量时间和精力来讨论可有可无的杂事，可是真正重大的决议反而能够轻松过关。

这是由于，在讨论很是专业并且金额庞大的事情时，通常人因为缺少专业知识，不敢随便发言，以避免失言，贻笑大方，所以多半都会确定（或逃避）该重大方案，而提些与主题无关的鸡毛蒜皮小事。相对的，对于简单的琐碎小事，因为日常你们都会接触到并且有至关的认识，反而意见特别多，帕金森称此现象为琐碎定律。

Unix 哲学

Unix哲学认为，软件组件应该很小，并且应该把注意力放在具体的事件上。将小的、简单的、定义良好的单元组合在一块儿，而不是使用大的、复杂的、多用途程序，这样可使构建系统变得更加容易。

像“微服务架构”这样的现代实践就应用了这种哲学。在该架构中，服务很小，且集中作某件事，使得复杂的行为由简单的构件组成。

Wadler 定律

该定律认为：在任何语言设计中，讨论这个列表中某个特性所花费的总时间与它位置的幂成正比。

1.语义

2.语法

3.词汇语法

4.注释的词汇语法

（简言之，若是在语义上花1小时来讨论，那将在注释语法上花8小时）。

与帕金森琐碎定律类似，Wadler 定律认为，当设计一种语言时，花在语言结构上的时间与这些特征的重要性相比很不成比例。

原则

在这篇文章中，做者表示原则是指导程序猿开发新应用的一些方针。在码代码的过程当中，咱们常常会遇到各类困难，固然也有各类约定俗成的规则。例如最简单的命名法，有的默认为使用下划线、使用小驼峰或大驼峰式的命名，只有了解这些规则，编写的代码才是优美的。

稳健性原则

在维基百科中，稳健性原则（Robustness Principle）描述为：“写代码要保守，要能接受其它方面的各类信息”。

该原则一般应用于服务器应用的开发，它表示发送的内容应该尽量少且符合要求。但若是能够处理不符合要求的输入，那么你的目标应该但愿容许各类非一致性的输入。

该原则的目标是构建一个稳健的系统，对于输入端，只要对方的意图仍能够理解，那么咱们就应该须要处理非标准格式的输入。然而，接受格式错误的输入有潜在的安全影响，特别是当这种输入的处理方式尚未通过良好的测试。

SOLID

该原则是一个缩写，即：

• S：单一功能原则

• O：开闭原则

• L：里氏替换原则

• I：接口隔离原则

• D：依赖反转原则

如上所示， SOLID 指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一块儿应用时，它们使得程序员能开发更容易进行软件维护和扩展的系统。SOLID常应用在测试的驱动开发上，而且是敏捷开发以及自适应软件开发的基本原则的重要组成部分。下面让咱们看看这5个基本原则都是什么吧。

单一功能原则

在维基百科的描述中，单一功能原则（Single responsibility principle）规定每一个类都应该有一个单一的功能，而且该功能应该由这个类彻底封装起来。全部它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。

这一原则代表模块或类应该只完成一件事。这意味着对程序特性的单个小修正，应该只须要在一个组件中进行更改。例如，更改验证密码的方式应该只须要更改程序特定的某个模块。

保持一个类专一于单一功能点，这样作的重要缘由是它会使得类更加稳健。若是咱们知道正在修改的组件只有一个功能，那么测试会变得更简单，新的修改也就好处理了。例如上面，修改密码验证应该只影响与密码验证相关的特性，若是咱们要对具备多功能的模块进行修改，这样进行推断就要复杂多了。

开闭原则

在面向对象的编程中，开闭原则规定：软件中的对象（类、模块、函数等等）对于扩展应该是开放的，可是对已存行为的修改是封闭的。这意味着，一个实体须要容许在不改变源代码的前提下变动它的行为。

该特性在产品化的环境中特别有价值，由于在产品化中改变源代码须要代码审查，例如单元测试等方法确保产品使用的质量。遵循这种原则的代码在扩展时并不发生改变，所以无需上述过程。

举个栗子，假设某个模块可以将 Markdown 文本转换为HTML。若是模块能够扩展新的特性，即能处理新提出的Markdown 特性而不修改模块内部，那么这就表示它对扩展是开放的。

这一原则与面向对象的编程特别相关，咱们能够设计易于扩展的对象，但也要避免设计不稳定的对象，由于它们的现有行为可能会以意想不到的方式发生改变。

里氏替换原则

里氏替换原则（Liskov Substitution principle）是对子类型的特别定义。里氏替换原则的内容能够描述为： 派生类（子类）对象能够在程序中代替其基类（父类）对象。也就是说，若是一个模块依赖于某个类，那么该模块就须要能使用该类的派生类，且不会发生系统错误。

举个栗子，若是咱们有一种方法，它能够从表征文件的结构中读取XML文本。若是该方法的基类是“file”，那么它能调用从“file”派生的任意类。

这一原则对于面向对象的编程很是重要，咱们必须仔细建模类的层次结构，以免让系统用户感到困惑。

接口隔离原则

接口隔离原则（interface-segregation principles）指明用户（client）应该不依赖于它不使用的方法。接口隔离原则拆分庞大臃肿的接口成为更小的和更具体的接口，这样用户将会只须要知道他们感兴趣的方法。这种缩小的接口也被称为角色接口（role interfaces）。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和从新部署。

举个栗子，假设咱们有一种可以从表征文件的结构中读取XML文档的方法。这种方法只须要读取字节以及在文件中前移或后移便可。若是该方法由于文件结构的一种非相关性特征改变而须要进行更新（如用于表征文件安全的权限模型的更新），则该原则无效。文件最好实现‘seekable-stream’接口并让XML reader使用。

该原则与面向对象编程具备特殊的相关性，其中接口、层次和抽象类型用于最小化不一样组件之间的耦合。鸭子类型（duck typing）经过消除显式接口来执行该原则。

依赖反转原则

在传统的应用架构中，低层次的组件设计用到高层次的组件中，这一点提供了逐步的构建一个复杂系统的可能。在这种结构下，高层次的组件直接依赖于低层次的组件去实现一些任务。这种对于低层次组件的依赖限制了高层次组件被重用的可行性。

依赖反转原则的目的是把高层次组件从对低层次组件的依赖中解耦出来，这样使得重用不一样层级的组件实现变得可能。把高层组件和低层组件划分到不一样的包/库，该方式也促进了这种解耦。因为低层组件是对高层组件接口的具体实现，所以低层组件包的编译是依赖于高层组件的，这颠倒了传统的依赖关系。众多的设计模式，好比插件、服务定位器或者依赖反转，则被用来在运行时把指定的低层组件实现提供给高层组件。

具体而言，依赖反转原则规定：

• 高层次的模块不该该依赖于低层次的模块，二者都应该依赖于抽象接口。

• 抽象接口不该该依赖于具体实现。而具体实现则应该依赖于抽象接口。

举个栗子，若是咱们有一个从网站读取元数据的程序，且主组件包含下载网站内容的组件和读取元数据的组件。若是咱们考虑依赖反转原则，那么主组件只能依赖于某些抽象组件，其中某个抽象组件只能获取比特数据、另外一个只能从比特流中读取元数据。主组件并不知道任何关于TCP/IP、HTTP或HTML等协议或格式的相关信息。

这一原则是比较复杂的，由于它彷佛反转了系统的依赖性关系。在实践中，该原则意味着独立的编排模块必须确保使用了正确的抽象类型实现。例如在上面的例子中，元数据读取模块仍是须要一些抽象类型的实现，即HTTP文件下载器和HTML元标签读取器。