当程序员谈论开发设计时，常常会聊到非常多的定律，而 GitHub 上的一个名为「hacker-laws」的仓库收录了一些最常见的定律、原则等，获得了 16.5k 的 Star。
还记得所有AI教程必提的「奥卡姆剃刀原则」吗：如无必要，勿增实体。
这条原则也被收藏，还有一些不太常见的费茨法则、盖尔定律、康威定律等，都被一一收入囊中。
写代码累了困了些法则让工作事半功倍。
前端 GitHub 地址：https://github.com/biaochenxuying/FrontEndGitHub
以下为【前端GitHub】的第 3 期内容。
定律
90-9-1 法则（1% 法则）
90-9-1 法则表明，在诸如维基这样的互联网社区中，90% 的用户只看内容并不参与互动，9% 的用户会参与讨论，而只有 1% 的用户会创造内容。
简而言之，这个曲线表明，新技术及其潜在影响通常会引发一轮浪潮。
团队快速使用这些新技术，但有时会对结果感到失望，这可能是因为该技术还不够成熟，或者现实应用还没有完全实现。
经过一段时间后，技术的能力提高了，使用它的实际机会会增加，最终团队也可以提高工作效率。
罗伊·阿马拉简洁地总结了这一点：我们倾向于高估技术短期内的影响，并低估其长期效应。
破窗效应
在破窗理论中认为，一些明显的犯罪迹象(或缺乏环保意识)会导致进一步的、更严重的犯罪(或环境的进一步恶化)。
破窗理论已应用于软件开发中，它表明劣质代码可能会影响后续优化的效率，从而进一步造成代码劣化；随着时间的推移，这种效应将会导致代码质量大幅下降。
没那么常见的法则，但也暗藏工作秘诀
阿姆达尔定律
阿姆达尔定律是一个显示计算任务潜在加速能力的公式。这种能力可以通过增加系统资源来实现，通常用于并行计算中。
它可以预测增加处理器数量的实际好处，然而增加处理器数量会受到程序并行性的限制。
举例说明：如果程序由两部分组成，A部分必须由单个处理器执行，B部分可以并行运行。那么向执行程序的系统添加多个处理器只能获得有限的好处。
它可以极大地提升部分 B 的运行速度，但部分 A 的运行速度将保持不变。
下图展示了一些运行速度的提升潜能的例子：
技术相关的原则
单一功能原则
每个模块或者类只应该有一项功能。
SOLID 的第一个原则。这个原则表明模块或者类只应该做一件事。实际上，这意味着对程序功能的单个小更改，应该只需要更改一个组件。例如，更改密码验证复杂性的方式应该只需要更改程序的一部分。
理论上讲，这使代码更健壮，更容易更改。知道正在更改的组件只有一个功能，这意味着测试更改更容易。使用前面的例子，更改密码复杂性组件应该只影响与密码复杂性相关的功能。变更具有许多功能的组件可能要困难得多。
开闭原则
实体应开放扩展并关闭修改。
SOLID 的第二个原则。这个原则指出实体（可以是类、模块、函数等）应该能够使它们的行为易于扩展，但是它们的扩展行为不应该被修改。
举一个假设的例子，想象一个能够将 Markdown 转换为 HTML 的模块。如果可以扩展模块，而不修改内部模块来处理新的 markdown 特征，而无需修改内部模块，则可以认为是开放扩展。如果用户不能修改处理现有 Markdown 特征的模块，那么它被认为是关闭修改。
这个原则与面向对象编程紧密相关，让我们可以设计对象以便于扩展，但是可以避免以意想不到的方式改变其现有对象的行为。
里氏替换原则
可以在不破坏系统的情况下，用子类型替换类型。
SOLID 的第三个原则。该原则指出，如果组件依赖于类型，那么它应该能够使用该类型的子类型，而不会导致系统失败或者必须知道该子类型的详细信息。
举个例子，假设我们有一个方法，读取 XML 文档。如果该方法使用基类型 file，则从 file 派生的任何内容，都能用在该方法中。如果 file 支持反向查找，并且 xml 解析器使用该函数，但是派生类型 network file 尝试反向查找时失败，则 network file 将违反该原则。
该原则与面向对象编程紧密相关，必须仔细建模、层次结构，以避免让系统用户混淆。
接口隔离原则
不应强制任何客户端依赖于它不使用的方法。
SOLID 的第四个原则。该原则指出组件的消费者不应该依赖于它实际上不使用的组件函数。
举一个例子，假设我们有一个方法，读取 XML 文档。它只需要读取文件中的字节，向前移动或向后移动。如果由于一个与文件结构不相关的功能发生更改（例如更新文件安全性的权限模型），需要更新此方法，则该原则已失效。文件最好实现 可查询流 接口，并让 XML 读取器使用该接口。
该原则与面向对象编程紧密相关，其中接口，层次结构和抽象类型用于不同组件的 minimise the coupling。Duck typing 是一种通过消除显式接口来强制执行该原则的方法。
依赖翻转原则
高级模块不应该依赖于低级实现。
SOLID 的第五个原则。该原则指出，更高级别的协调组件不应该知道其依赖项的详细信息。
举个例子，假设我们有一个从网站读取元数据的程序。我们假设主要组件必须知道下载网页内容的组件，以及可以读取元数据的组件。如果我们考虑依赖反转，主要组件将仅依赖于可以获取字节数据的抽象组件，然后是一个能够从字节流中读取元数据的抽象组件，主要组件不需要了解 TCP、IP、HTTP、HTML 等。
这个原则很复杂，因为它似乎可以反转系统的预期依赖性（因此得名）。实践中，这也意味着，单独的编排组件必须确保抽象类型的正确实现被使用（例如在前面的例子中，必须提供元数据读取器组件、HTTP 文件下载功能和 HTML 元标签读取器）。然后，这涉及诸如 Inversion of Control 和 Dependency Injection 之类的模式。
切斯特森围栏 (Chesterson’s Fence)
在了解现有情况背后的原因之前，不应该进行改进。
该原则与软件工程中的消除技术负债 (Technical debt) 相关。程序的每一行最初都是出于某种原因编写的，因此根据切斯特森围栏原则，在更改或删除代码之前，即使看起来似乎是多余的或不正确的，也应该尝试完全理解代码的上下文和含义。
该原则的名字来源于一则故事。一个男人横穿马路中央的栅栏，他向市长抱怨这道栅栏没有用还挡路，并要求拆除它。市长问他为什么要在那里建栅栏，那个人回答说不知道。市长接着说：“如果你不知道它的用途，我肯定不会让你把它拆了。你去查查它的用途，之后我可能会允许你拆掉它。”
哲学意味的原则
鲁棒性原则
在自己所做的事情上要保守, 在接受别人的事情上要自由。
通常应用于服务器应用程序开发中，该原则指出，你发送给其他人的内容应尽可能最小且符合要求，并且处理不符合要求的输入。
该原则的目标是构建稳健的系统。如果可以理解意图，它们可以处理不良的输入。但是，接受错误格式的输入可能存在安全隐患，特别是此类的输入未经过充分测试。
不要重复你自己原则
系统中，每一块知识都必须是单一、明确而权威的。
DRY 是 Do not Repeat Yourself 的缩写。这个原则旨在帮助开发人员减少代码的重复性，并将公共代码保存在一个地方。最初由安德鲁·亨特和戴夫·托马斯在 1999 年出版的《程序员修炼之道》中引用。
与 DRY 相反的是 WET（功能实现两次或者喜欢打字 Write Everything Twice or We Enjoy Typing）。
实际上，如果你在两个或更多的地方有相同的功能，你可以使用 DRY 原则将它们合并为一个，并在任何你需要的地方重复使用。
你不需要它法则
只有当你需要某些东西的时候，才去实现它们，而不是在你预见的时候。
极限编程原则告诫开发人员，他们应该只实现当前所需的功能，并避免实现未来需要的功能，仅在必要时才实现。
遵守这一原则可以减小代码库大小，同时避免时间和生产力浪费在没有价值的功能上。
KISS原则
保持简单和直白。
KISS 原则指明了如果大多数的系统能够保持简单而非复杂化，那么他们便能够工作在最佳状态。因此，简单性应该是设计时的关键指标，同时也要避免不必要的复杂度。这个短语最初出自 1960 年的美国海军飞机工程师凯利 · 约翰逊 (Kelly Johnson)。
这一原则的最好例证便是约翰逊给设计工程师一些实用工具的故事。那时的他们正面临着一个挑战，即他们参与设计的喷气式飞机必须能够让普通的机械师在战场上仅仅用这些工具进行维修，因此，“直白”这个词应指的是损坏的事物本身和修复用工具的复杂度两者之间的关系，而非工程师们自身的能力水平。
还有很多的法则和原则没有一一指出，需要的小伙伴请点击下面的链接打开查看。
hacker-laws 中文地址：https://github.com/nusr/hacker-laws-zh
前端 GitHub 地址：https://github.com/biaochenxuying/FrontEndGitHub
平时如何发现好的开源项目，可以看看这篇文章：GitHub 上能挖矿的神仙技巧 – 如何发现优秀开源项目。
觉得有用 欢就收藏，顺便点个赞吧，你的支持是我最大的鼓励！
在公众号后台回复：电子书 ，可以获得 160 本前端精华书籍哦。
往期精文
全球最火的WEB开发学习路线！没有之一！3 天就在GitHub收获了接近 1w 点赞
GitHub上最火的、最值得前端学习的数据结构与算法项目！没有之一
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92487 人正在系统学习中
来源：前端GitHub
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！