这里只记录了一些自己觉得有收获得定律，完整的文章链接在这里https://github.com/nusr/hacker-laws-zh
当人们谈论开发时，会聊到许多定律。这个仓库收录了一些最常见的定律。
❗: 这个仓库包含对一些定律、原则以及模式的解释，但不提倡其中任何一个。 它们的应用始终存在着争论，并且很大程度上取决于你正在做什么。
破窗效应 (The Broken Windows Theory)
在破窗理论中认为，一些明显的犯罪迹象(或缺乏环保意识)会导致进一步的、更严重的犯罪(或环境的进一步恶化)。
破窗理论已应用于软件开发中，它表明劣质代码(或 Technical Debt)可能会影响后续优化的效率，从而进一步造成代码劣化；随着时间的推移，这种效应将会导致代码质量大幅下降。
盖尔定律 (Gall's Law)
一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行，无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。
约翰·盖尔 (John Gall)
盖尔定律说明了设计高度复杂的系统很可能会失败。它们很难一蹴而就，更多是从简单的系统逐渐演变而来。
最典型的例子便是互联网。如今的互联网是一个高度复杂的系统，而它最早只是被定义为一种在学术机构之间共享内容的方式。互联网成功实现了最初的目标，并且随着时间不断演化，最终成就了如今的复杂繁荣。
侯世达定律 (Hofstadter's Law)
即使考虑到侯世达定律，它也总是比你预期的要长。
侯世达 (Douglas Hofstadter)
在估计需要多长时间开发时，你可能会听到此定律。软件开发似乎有这样一条定理，即我们往往不能准确地估计需要多长时间才能完成。
柯林汉定律 (Kernighan's Law)
调试在一开始就比编写程序困难一倍。因此，按照定义，如果你的代码写得非常巧妙，那么你就没有足够的能力来调试它。
布莱恩·柯林汉 (Brian Kernighan)
柯林汉定律是以布莱恩·柯林汉 (Brian Kernighan) 的名字命名的，引述自柯林汉和普劳格 (P.J. Plauger) 的《编程格调》 (The Elements of Programming Style) 一书中的一句话：
每个人都知道，调试在一开始就比编写程序困难一倍。那么，如果您在编写它时尽可能地巧妙，又如何来调试它？
尽管这有些夸张，但它提出的论点是，简单的代码会比复杂的代码更可取，因为调试复杂代码的过程中出现的任何问题都会十分棘手，甚至无法解决。
林纳斯定律 (Linus's Law)
足够多的眼睛，就可让所有问题浮现。
Eric S. Raymond
简单地说，能够看到问题的人越多，有人解决过相关的问题或事情的可能性就越高。
最初该定律是用来描述开源模型对于项目的价值的，并适用于任意的软件项目。同时它也可以扩展到开发流程之中——更多的代码审查、更多的静态分析和多重测试可以让问题更加明显和容易识别。
林纳斯定律的一个更正式的说法如下：
如果有足够大的测试员和联合开发人员基础，那么几乎每个问题都能很快被特征化，从而让以前遇到过类似问题的人解决。
这条定律最早出现在 Eric S. Raymond 所著书 "The Cathedral and the Bazaar" 中，并以 Linus Torvalds 的名字命名以作纪念。
墨菲定律 (Murphy's Law / Sod's Law)
凡是可能出错的事就一定会出错。
出自 爱德华·A·墨菲 ， 墨菲定律 说明了如果一件事有可能出错，那么就一定会出错。
这是一句开发人员间的俗语，在开发、测试甚至在生产中都有可能会发生一些令人意想不到的事情。而这一定律也可以参考在英式英语中更为常见的 索德定理 ：
如果某件事可能出错，那么它一定会在最糟糕的时候发生。
这些定律常常用于幽默嘲弄。但是，类似于 Confirmation Bias 和 Selection Bias 的现象很容易导致人们过分强调这些定律（即在大部分情况下，一件事的成功会显得司空见惯；而失败才会引起更多的注意和讨论）。
奥卡姆剃刀 (Occam's Razor)
如无必要，勿增实体。
奥卡姆的威廉 (William of Ockham)
奥卡姆剃刀指出，在几种可能的解决方案之中，最有可能的解决方案便是概念和假设最少的那个。因为这个解决方案最为简单，只解决了问题，并且没有引入额外的复杂度和可能的负面后果。
过早优化效应 (Premature Optimization Effect)
过早优化是万恶之源。
高德纳 (唐纳德克努特的中文名)
在高德纳的《goto 语句的结构化编程》论文中，他写到：“程序员们浪费了大量的时间去思考或者担心他们的程序中的非关键部分的速度。而在考虑调试和维护的时候，这些所谓提高效率的做法实际上十分不妥。我们应该放弃小的效率点，并且要在 97% 的时间提醒自己，过早优化是万恶之源。而且连那关键的 3% 也不能够放过。”
然而，过早优化 （简而言之）可以定义为在我们知道需要做什么之前进行优化。
复杂性守恒定律 (The Law of Conservation of Complexity or Tesler's Law)
该定律表明系统中存在着一定程度的复杂性，并且不能减少。
系统中的某些复杂性是无意的。这是由于结构不良，错误或者糟糕的建模造成的。这种无意的复杂性可以减少或者消除。然而，由于待解决问题固有的复杂性，某些复杂性是内在的。这种复杂性可以转移，但不能消除。
该定律有趣的一点是，即使简化整个系统，内在的复杂性也不会降低。它会转移到用户，并且用户必须以更复杂的方式行事。
得墨忒耳定律 (The Law of Demeter)
别和陌生人讲话。
得墨忒耳定律又称最少知识原则，是一条与面向对象语言有关的软件设计原则。
该定律表明，软件的一个单元应该只与其直接合作者交谈。比如对象 A 引用了对象 B，对象 B 引用了对象 C，则 A 可以直接调用 B 的方法，但不应直接调用 C 的方法。所以如果 C 有一个 dothing() 的方法，A 不应该直接调用，而是使用 B.getC().doThis()。
遵循这一定律可以限制代码更改的范围，使其以后更容易维护、更安全。
Unix 哲学 (The Unix Philosophy)
Unix 哲学指软件组件应该很小，并专注于做一件特定的事情。将小而简单以及定义良好的单元组合在一起，而不是使用大而复杂的多用途程序，可以更轻松地构建系统。
像微服务架构这种现代实践可以认为是这种哲学的应用，其中服务很小，集中于做一件特定的事情，由简单的构建块组成复杂的行为。
帕累托法则 (The Pareto Principle or The 80/20 Rule)
生活中大多数事情不是均匀分布的。
帕累托法则可以帮你认识到大多数结果来自少数投入：
某个软件的 80％ 代码只占了总分配时间的 20％（相反，最难的 20％ 代码部分占用了 80％ 的时间）
20％ 的努力产生了 80％ 的结果
20％ 的工作创造了 80％ 的收入
20％ 的错误导致了 80％ 的崩溃
20％ 的功能导致了 80％ 的使用量
在 20 世纪 40 年代，公认为质量控制之父的美国罗马尼亚工程师约瑟夫·朱兰博士，开始将帕累托法则应用于质量问题。
这个原则也被称为二八法则，重要的少数法则和因素稀疏原则。
SOLID
这是一个缩写，指的是：
S：单一功能原则 (The Single Responsibility Principle)
O：开闭原则 (The Open/Closed Principle)
L：里氏替换原则 (The Liskov Substitution Principle)
I：接口隔离原则 (The Interface Segregation Principle)
D：依赖反转原则 (The Dependency Inversion Principle)
这些是 Object-Oriented Programming 的关键原则。诸如此类的设计原则能够帮助开发人员构建更易于维护的系统。
单一功能原则 (The Single Responsibility Principle)
每个模块或者类只应该有一项功能。
SOLID 的第一个原则。这个原则表明模块或者类只应该做一件事。实际上，这意味着对程序功能的单个小更改，应该只需要更改一个组件。例如，更改密码验证复杂性的方式应该只需要更改程序的一部分。
理论上讲，这使代码更健壮，更容易更改。知道正在更改的组件只有一个功能，这意味着测试更改更容易。使用前面的例子，更改密码复杂性组件应该只影响与密码复杂性相关的功能。变更具有许多功能的组件可能要困难得多。
开闭原则 (The Open/Closed Principle)
实体应开放扩展并关闭修改。
SOLID 的第二个原则。这个原则指出实体（可以是类、模块、函数等）应该能够使它们的行为易于扩展，但是它们的扩展行为不应该被修改。
举一个假设的例子，想象一个能够将 Markdown 转换为 HTML 的模块。如果可以扩展模块，而不修改内部模块来处理新的 markdown 特征，而无需修改内部模块，则可以认为是开放扩展。如果用户不能修改处理现有 Markdown 特征的模块，那么它被认为是关闭修改。
这个原则与面向对象编程紧密相关，让我们可以设计对象以便于扩展，但是可以避免以意想不到的方式改变其现有对象的行为。
里氏替换原则 (The Liskov Substitution Principle)
可以在不破坏系统的情况下，用子类型替换类型。
SOLID 的第三个原则。该原则指出，如果组件依赖于类型，那么它应该能够使用该类型的子类型，而不会导致系统失败或者必须知道该子类型的详细信息。
举个例子，假设我们有一个方法，读取 XML 文档。如果该方法使用基类型 file，则从 file 派生的任何内容，都能用在该方法中。 如果 file 支持反向查找，并且 xml 解析器使用该函数，但是派生类型 network file 尝试反向查找时失败，则 network file 将违反该原则。
该原则与面向对象编程紧密相关，必须仔细建模、层次结构，以避免让系统用户混淆。
接口隔离原则 (The Interface Segregation Principle)
不应强制任何客户端依赖于它不使用的方法。
SOLID 的第四个原则。该原则指出组件的消费者不应该依赖于它实际上不使用的组件函数。
举一个例子，假设我们有一个方法，读取 XML 文档。它只需要读取文件中的字节，向前移动或向后移动。如果由于一个与文件结构不相关的功能发生更改（例如更新文件安全性的权限模型），需要更新此方法，则该原则已失效。文件最好实现 可查询流 接口，并让 XML 读取器使用该接口。
该原则与面向对象编程紧密相关，其中接口，层次结构和抽象类型用于不同组件的 minimise the coupling。 Duck typing 是一种通过消除显式接口来强制执行该原则的方法。
依赖反转原则 (The Dependency Inversion Principle)
高级模块不应该依赖于低级实现。
SOLID 的第五个原则。该原则指出，更高级别的协调组件不应该知道其依赖项的详细信息。
举个例子，假设我们有一个从网站读取元数据的程序。我们假设主要组件必须知道下载网页内容的组件，以及可以读取元数据的组件。如果我们考虑依赖反转，主要组件将仅依赖于可以获取字节数据的抽象组件，然后是一个能够从字节流中读取元数据的抽象组件，主要组件不需要了解 TCP、IP、HTTP、HTML 等。
这个原则很复杂，因为它似乎可以反转系统的预期依赖性（因此得名）。实践中，这也意味着，单独的编排组件必须确保抽象类型的正确实现被使用（例如在前面的例子中，必须提供元数据读取器组件、HTTP 文件下载功能和 HTML 元标签读取器）。然后，这涉及诸如 Inversion of Control 和 Dependency Injection 之类的模式。
不要重复你自己原则 (The DRY Principle)
系统中，每一块知识都必须是单一、明确而权威的。
DRY 是 Do not Repeat Yourself 的缩写。这个原则旨在帮助开发人员减少代码的重复性，并将公共代码保存在一个地方。最初由安德鲁·亨特和戴夫·托马斯在 1999 年出版的《程序员修炼之道》中引用。
与 DRY 相反的是 WET（功能实现两次或者喜欢打字 Write Everything Twice or We Enjoy Typing）。
实际上，如果你在两个或更多的地方有相同的功能，你可以使用 DRY 原则将它们合并为一个，并在任何你需要的地方重复使用。
你不需要它原则 (YAGNI)
这是 You Aren't Gonna Need It 的缩写。
只有当你需要某些东西的时候，才去实现它们，而不是在你预见的时候。
Ron Jeffries 是极限编程的创始人之一以及书籍《Extreme Programming Installed》的作者。
极限编程原则告诫开发人员，他们应该只实现当前所需的功能，并避免实现未来需要的功能，仅在必要时才实现。
遵守这一原则可以减小代码库大小，同时避免时间和生产力浪费在没有价值的功能上。