注意：在语义上，计算机定律不是一成不变的法则，而是经验法则或假定法则。
摩尔定律（经验法则：Moore's law）
摩尔定律是intel创始人Gordon Moore提出，讲的是当价格不变时，IC（集成电路）上可容纳的元器件的数目，
大约每隔18~24个月便会增加一倍，性能也会提升一倍。
换句话说，花费同样的钱在2年后购买的设备的性能要比当前购买的设备的性能翻上一翻。或者说当前购买的
设备会在2年后下降一半的价格。
摩尔定律只是基于对电子设备发展状况的一些观测结果所作出的推测，并不是一个恒定的自然（物理）定律。
基本上适用于描述半导体行业制造较小晶体管的能力（登纳德缩放）。
自2010年以来，半导体行业的发展速度由于技术成本问题已经放缓，平均低于摩尔定律的预测速度。当然也不
排除某些半导体厂商宣布他们依然遵循摩尔定律（如三星）。
参考：
wiki：https://en.wikipedia.org/wiki/Moore%27s_law
百度：https://baike.baidu.com/item/%E6%91%A9%E5%B0%94%E5%AE%9A%E5%BE%8B
摩尔第二定律（经验法则：Moore's second law 或 Rock's law）
又称洛克定律，即半导体芯片制造厂的成本每4年翻一倍。强调创新研发的成本制约问题。
说明了摩尔定律在制造成本、光刻等关键技术以及物理基础等方面的困难和制约，为维护摩尔定律的基本原理，
学术界在分子电子学、量子技术等方向上做出了更多的工作。
参考：
wiki：https://en.wikipedia.org/wiki/Moore%27s_second_law
反摩尔定律
Google（谷歌）的 CEO埃里克·施密特在一次采访中指出，如果你反过来看摩尔定理，一个 IT 公司如果今天
和十八个月前卖掉同样多的、同样的产品，它的营业额就要降一半。
反摩尔定理对于所有的 IT 公司来讲，都是非常可悲的，因为一个 IT 公司花了同样的劳动，却只得到以前一
半的收入。反摩尔定理逼着所有的硬件设备公司必须赶上摩尔定理规定的更新速度。事实上，所有的硬件和设
备生产厂活得都是非常辛苦的。
参考：
百度：https://baike.baidu.com/item/%E5%8F%8D%E6%91%A9%E5%B0%94%E5%AE%9A%E7%90%86
安迪比尔定理（Andy and Bill's law）
“Andy gives, Bill takes away.（安迪提供什么，比尔拿走什么。）” 安迪指英特尔前CEO安迪·格鲁夫，
比尔指微软前任CEO比尔·盖茨，这句话的意思是，硬件提高的性能，很快被软件消耗掉了。是对IT产业中软件和
硬件升级换代关系的一个概括。
在过去的二十年里，英特尔处理器的速度每十八个月翻一番，计算机内存和硬盘的容量以更快的速度在增长。
但是，微软的操作系统等应用软件越来越慢，也越做越大。所以，现在的计算机虽然比十年前快了一百倍，
运行软件感觉上还是和以前差不多。
而且，过去整个视窗操作系统不过十几兆大小，现在要几千兆，应用软件也是如此。虽然新的软件功能比以前
的版本强了一些，但是，增加的功能绝对不是和它的大小成比例的。因此，一台十年前的计算机能装多少应用程序，
现在的也不过装这么多，虽然硬盘的容量增加了一千倍。更糟糕的是，用户发现，如果不更新计算机，
现在很多新的软件就用不了，连上网也是个问题。而十年前买得起的车却照样可以跑。
过去搞得 BASIC 只有几十 K，而现在搞一个.NET 就要几百兆，编程的语言越来越好用，同时效率却越来越低，
比如，今天的 Java 就比 C++ 效率低得多，C++ 又比二十年前的 C 效率低。因此，即使是同样功能的软件，
今天的比昨天的占用硬件资源多是一件在所难免的事。
尽管英特尔从这笔交易中获得了利润，但格罗夫仍感到盖茨没有充分利用英特尔芯片的强大功能，并且事实上他希望拒绝升
级软件以实现最佳硬件性能。这也表现了格罗夫（Grove）对Microsoft软件在Intel硬件上的统治地位的无奈之情。
That new software will always consume any increase in computing power that new hardware can provide.
参考：
wiki：https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
百度：https://baike.baidu.com/item/%E5%AE%89%E8%BF%AA%E6%AF%94%E5%B0%94%E5%AE%9A%E7%90%86?fromId=2066996
阿姆达尔定律（经验法则：Amdahl's law）
代表了处理器并行运算之后效率提升能力的一个量化标准。
公式为S=1/(1-a+a/n)
当1-a=0时，没有串行，只有并行，最大加速比s=n
当a=0时，只有串行，没有并行，最小加速比s=1
当n趋于正无穷时，极限加速比为1/（1-a），即加速比的上限
并行计算中的加速比是用并行前的执行速度和并行后的执行速度之比来表示的，它表示了在并行化之后的效率提升情况。
Eg：如果一个程序单个线程完成需要20个小时，但是该程序的其中1个小时部分无法并行化，那么剩余的19个小时
的执行时间是可以并行化的，此时无论启用多少个线程用于该程序的并行执行，其最终的执行时间都不能少于一小时，
因此理论上的加速比为单线程性能的最多20倍（1/(1-0.95) = 20）, 0.95指其中95%的时间可以并行化。然而实际上
只能尽可能接近而不能达到绝对的20倍，即假如此时有100个线程（或称处理节点）并行执行，
则加速比S=1/(1-0.95 + 0.95/100)
参考：
wiki：https://en.wikipedia.org/wiki/Amdahl%27s_law
百度：https://baike.baidu.com/item/%E9%98%BF%E5%A7%86%E8%BE%BE%E5%B0%94%E5%AE%9A%E5%BE%8B/10386960
贝尔定律（经验法则：Bell's law of computer classes）
大约每10年，就会有一个基于新的编程平台、网络和接口并且价格更低的新型计算机面世，同时导致计算机向新的行业
领域发展并促进新行业的建立，降低成本，完善更多用户新的需求。
参考：
wiki：https://en.wikipedia.org/wiki/Bell%27s_law_of_computer_classes
格罗施定律（Grosch's law）
来自Grosch对计算机性能的观察：
如果计算机A的价格是计算机B的两倍，那么我们期望计算机A的速度是计算机B的四倍
即当价格翻倍时，我们应该至少获得四倍的速度。
引申为：计算机越昂贵，其性价比就越好，这意味着低成本计算无法在市场上竞争
参考：
wiki：https://en.wikipedia.org/wiki/Grosch%27s_law
古斯塔夫森定律（Gustafson's law）
古斯塔夫森定律解决了阿姆达尔定律的缺点：即解决了执行工作量不会随着资源的改善而改变的问题（包括调度、
管理和执行并行任务所需要的开销）。
比如一个应用程序在一个固定的期限内完成一个特定的操作。由此而来的性能收益可以被用来更快速地完成工作，但是，
性能收益很有可能仅仅被用来在相同的固定期限内完成更多的工作。当这种情况发生时，性能收益并没有传递给用户。
尽管这样，应用程序完成了更多的工作或者提供了额外的功能。
所以，我们仍然可以从运行在多核环境中的并行应用程序获得显著效益。
参考：
wiki：https://en.wikipedia.org/wiki/Gustafson%27s_law
百度：https://baike.baidu.com/item/%E5%8A%A0%E9%80%9F/13003916
海兹定律（Haitz's law）
海兹定律是对发光二极管（LED）多年来稳步改进的观察和预测。适用于发光半导体器件的生产。
它声称，对于给定的光的波长（颜色），每十年，每流明（可见光的发射的单位）的成本降低10倍，而每个LED包装产生的光量增加20倍。
预测每个流明的成本和每个包装的光量成指数增长，而LED将成为最高效的光源。
2017年飞利浦照明使用LED灯丝技术在迪拜提供200流明/瓦的功效的消费类LED灯。
参考：
wiki：https://en.wikipedia.org/wiki/Haitz%27s_law
库米定律（Koomey's law）
Koomey定律描述了计算硬件历史上的趋势，大约半个世纪以来，每焦耳耗散的能量的计算数量大约每1.57年增加一倍
在固定的计算负载下，我们所需的电池电量每2年（或18个月，一般是取2年加1年的平均值(24 + 12)/2=18）将减少一半。
认为计算机性能的提高，各类组件如电容的体积缩小，通信模块之间的通信时间的缩短，都能大大提高能源效率。
参考：
wiki：https://en.wikipedia.org/wiki/Koomey%27s_law
百度：https://baike.baidu.com/item/%E5%BA%93%E6%A2%85%E5%AE%9A%E5%BE%8B
莱纳斯定律（Linus's law）
以linux内核创建人名字命名，意思是如果有足够大的测试人员和联合开发人员，几乎每个问题都能迅速发现。
这是软件审查的一种简单形式。"given enough eyeballs, all bugs are shallow"（如果有足够多的眼睛，
所有的 bug 都将无所遁形。）
参考：
wiki：https://en.wikipedia.org/wiki/Linus%27s_law
梅特卡夫定律（Metcalfe's law）
是一个关于网络的价值和网络技术的发展的定律，其内容是：一个网络的价值等于该网络内的节点数的平方，
而且该网络的价值与联网的用户数的平方成正比。
该定律指出，一个网络的用户数目越多，那么整个网络和该网络内的每台计算机的价值也就越大。
梅特卡夫定律与以下事实有关：n节点可以数学上表示为n（n-1）/ 2，渐近于n的平方。
参考：
wiki：https://en.wikipedia.org/wiki/Metcalfe%27s_law
百度：https://baike.baidu.com/item/%E6%A2%85%E7%89%B9%E5%8D%A1%E5%A4%AB%E5%AE%9A%E5%BE%8B
波拉克法则（Pollack's rule）
关于微体系结构架构方面的，如果芯片的设计复杂度增加一倍，它的性能会得到根号2倍的提升。
即同制程工艺下，处理器的性能提升幅度，是芯片面积（晶体管数量）提升的平方根。
参考：
wiki：https://en.wikipedia.org/wiki/Pollack%27s_rule
维尔斯定律（Wirth's law）
它指出软件变得越来越慢，而硬件变得越来越快。或表达为软件变慢的速度比硬件变慢的速度快。
呼吁开发“更精简”的软件。
参考：
wiki：https://en.wikipedia.org/wiki/Wirth%27s_law
附录：软件开发定律
1. 墨菲定律（Murphy’s Law）：如果事情可能出错，它就会出错。
2. 布鲁克定律（Brook’s Law）：为已经延期的软件项目增加人手只会让项目延期得更厉害。
3. 霍夫施塔特定律（Hofstadter’s Law）：即使你考虑到了霍夫施塔特定律，项目的实际完成时间总是比预期的要长。是关于准确预估完成复杂任务所需时间的难度。
4. 康威定律（Conway’s Law）：软件的结构反映了开发软件的组织的结构。或指组织所设计的系统的结构受限于组织的通信结构。
5. 波斯托定律（Postel’s Law）或鲁棒性法则：保守输出，自由输入。
6. 帕累托法则（Pareto Principle）：生活中大多数事情不是均匀分布的。，对于很多现象，80％的后果源于 20％的原因。
7. 彼得法则（The Peter Principle）：在一个等级制度中，每个员工都倾向于晋升到他无法胜任的职位。
8. 基尔霍夫法则（Kerchkhoff’s Principle）：在密码学中，系统应该是安全的，即使系统的所有东西都是公开的——除了一小部分信息——秘钥。
9. 莱纳斯定律（Linus’s Law）：如果有足够多的眼睛，所有的 bug 都将无所遁形。
10.摩尔定律（Moore’s Law）：集成电路上的晶体管数量大约每 18 个月会增加一倍。
11.沃斯定律（Wirth’s Law）：软件比硬件更容易变慢。
12.九九法则（Ninety-Ninety Rule）：前 90％的代码占用了 10％的时间，其余的 10％代码占用了剩下的 90％时间。
13.克努特优化法则（Knuth’s Optimization Principle）：过早优化是万恶之源。
14.诺维格定律（Norvig’s Law）：任何超过 50％渗透率的技术都不会再次翻倍（无论在多少个月内）。
15.真香定律：又称境泽现象。现在主要用来调侃某人喊口号抵制某事物后又自打脸表示对其喜爱的行为。“别更新了，我学不动了！……真香。”
16.隐式接口定律 (Hyrum's Law)：当 API 有足够多的用户时，你在合同中的承诺已不重要：你系统的所有可观察行为都将被某些人所依赖。
17.帕金森定理 (Parkinson's Law)：在工作能够完成的时限内，工作量会一直增加，直到所有可用时间都被填满为止。该理论认为，团队在截止日期之前效率低下，然后在截止日期前赶紧完成工作，从而使实际截止日期变得随意。
18.普特定律 (Putt's Law)：技术由两类人主导，一类是纯粹的管理人员， 一类是纯粹的技术人员。
19.抽象泄漏定律 (The Law of Leaky Abstractions)：在某种程度上，所有非平凡的抽象都是有泄漏的。
20.Unix 哲学 (The Unix Philosophy)：指软件组件应该很小，并专注于做一件特定的事情。将小而简单以及定义良好的单元组合在一起，而不是使用大而复杂的多用途程序，像微服务。
21.Spotify 模型 (The Spotify Model)：Spotify 模型是团队和组织结构的一种方法，在此模型中，团队围绕功能而非技术进行组织。
22.沃德勒定律 (Wadler's Law)：任何语言设计中，讨论下面列表中某个要素所花费的总时间与其位置成正比。（1）语义 (Semantics)（2）语法 (Syntax)（3）词法 (Lexical syntax)（4）注释语法 (Lexical syntax of comments)
23.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)
24.设计模式六大原则：开闭原则（Open Close Principle）：对扩展开放，对修改关闭。实现一个热插拔的效果，使程序的扩展性好，易于维护和升级。
里氏代换原则（Liskov Substitution Principle）：是对开闭原则的补充。任何基类可以出现的地方，子类一定可以出现。是对实现抽象化的具体步骤的规范。
依赖倒转原则（Dependence Inversion Principle）：是开闭原则的基础。具体内容：针对接口编程，依赖于抽象而不依赖于具体。
接口隔离原则（Interface Segregation Principle）：使用多个隔离的接口，比使用单个接口要好。降低类之间的耦合度。
迪米特法则，又称最少知道原则（Demeter Principle）：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
合成复用原则（Composite Reuse Principle）：尽量使用合成/聚合的方式，而不是使用继承。
25.DRY原则：Do not Repeat Yourself，旨在帮助开发人员减少代码的重复性。
26.WET原则：Write Everything Twice or We Enjoy Typing，功能实现两次或者喜欢打字，与 DRY 相反。
27.YAGNI原则：You Aren't Gonna Need It，只有当你需要某些东西的时候，才去实现它们，而不是在你预见的时候。遵守这一原则可以减小代码库大小，同时避免时间和生产力浪费在没有价值的功能上。
参考：
https://www.infoq.cn/article/1dyfkOTeohgHSCh_Xle9
https://github.com/nusr/hacker-laws-zh/blob/master/README.md
