极简的极客法则

[toc]

写在前面

原文是hacker-laws ，作者做了翻译、归纳、整理、夹带私货；
阅读hacker laws 有助于coder 更好的开发； here we go!

定律

90-9-1 法则 (90–9–1 Principle or 1% Rule)

在诸如维基这样的互联网社区中，90% 的用户只看内容并不参与互动，9% 的用户会参与讨论，而只有 1% 的用户会创造内容。

阿姆达尔定律 (Amdahl’s Law)

并行计算中，有些部分可以被多核心并行处理，有些部分只能串行处理，增加核心对速度的提升的收益会边际递减

破窗效应 (The Broken Windows Theory)

在破窗理论中认为，恶化若不修复，会导致进一步更严重的恶化参见：

布鲁克斯法则 (Brooks’s Law)

软件开发后期，添加人力只会使项目开发得更慢。因为有些事情无法分割，切增加沟通成本（和阿姆达尔有点像）
《人月神话》大篇幅在讲这个

CAP 定理 (CAP Theorem or Brewer’s Theorem)

CAP 定理由 Eric Brewer 所定义，它指出对于分布式数据存储来说，不可能同时满足以下三点，可以有侧重，例如金融交易系统的强一致性，淘宝的可用性等：

一致性 (Consistency)：每个终端都会接收到最新的数据，或者返回错误。
可用性 (Availability): 每个终端都会接收到一个非错误的响应，但不能保证该数据是最新的数据。
分区容错性 (Partition Tolerance)：当节点之间任意数量的网络请求失败时，系统能按预期继续运行（脑裂后还可以保证使用）。

康威定律 (Conway’s Law)

如果一个组织被分散成许多小而无联系的单元，那么它开发的软件也是小而分散的。组织架构会体现在软件架构上（分形）

坎宁汉姆定律 (Cunningham’s Law)

在网络上想得到正确答案的最好方法不是提问题，而是发布一个错误的答案，引起辩论（不建议这么做，现在网上已经一堆的错误回答）

邓巴数字 (Dunbar’s Number)

邓巴数字是对一个人能够保持稳定社会关系的人数的认知极限——在这种关系中，邓巴数字的估计值一般在 100 至 250 之间。所以有些以扁平化为珍宝的公司在扩张时管理会有问题，对我们个人的启发是，可以交一两个社交牛的朋友，可以交换新事物。

邓宁-克鲁格效应 (The Dunning-Kruger Effect)

无能的人往往不会意识到自己的无能。而得出正确答案所需要的技能，正是你认识到何为正确答案所需要的技能。虚幻的优越性产自无知

费茨法则 (Fitts’s Law)

该法则指出，移动到目标区域所需的时间是到目标的距离除以目标宽度的函数。
费茨法则决定了在设计 UX 或 UI 时，交互元素应该尽可能大，而用户注意力区域和交互元素之间的距离应该尽可能小。这会对设计产生影响，例如将相近的任务进行归类分组等。

盖尔定律 (Gall’s Law)

完整的复杂系统不是设计成的，而是一步步的修补和更改变成现在的样子。

古德哈特定律 (Goodhart’s Law)

当一个措施本身成为目标时，它就不再是一个好的措施，像为了kpi而kpi，在方法中迷失目的

汉隆的剃刀 (Hanlon’s Razor)

能解释为愚蠢的，就不要解释为恶意的

席克定律 (Hick’s Law or Hick-Hyman Law)

决策时间和可供选择的选项数量呈对数增长关系。

侯世达定律 (Hofstadter’s Law)

结果往往低于目标，即使考虑到了这个点。

哈特伯定律 (Hutber’s Law)

对一个系统的改进会导致其他部分的恶化；或者它会将其他的恶化隐藏起来，并导致系统整体状态的退化。

技术成熟度曲线 (The Hype Cycle or Amara’s Law)

人有动物性-短时。我们倾向于过高估计技术在短期内的影响，并低估长期效应。

隐式接口定律 (Hyrum’s Law or The Law of Implicit Interfaces)

当你的 API 有足够多的用户时，API 的所有行为最终都会被其他人所依赖，大家不会一直看文档，很多公司都在取消文档工程师，转而提升用户使用体验。

柯林汉定律 (Kernighan’s Law)

调试在一开始就比编写程序困难一倍。因此，按照定义，如果你的代码写得非常巧妙，那么你就没有足够的能力来调试它。

林纳斯定律 (Linus’s Law)

简单地说，能够看到问题的人越多，有人解决过相关的问题或事情的可能性就越高。

梅特卡夫定律 (Metcalfe’s Law)

在网络理论中，系统的价值约等于系统用户数的平方，人的作用很大。

摩尔定律 (Moore’s Law)

集成电路中的晶体管数量大约每两年翻一番。价格不变，芯片性能两年一番。

墨菲定律 (Murphy’s Law / Sod’s Law)

凡是可能出错的事就一定会出错。

奥卡姆剃刀 (Occam’s Razor)

如无必要，勿增实体。

帕金森定理 (Parkinson’s Law)

在工作能够完成的时限内，工作量会一直增加，直到所有可用时间都被填满为止，所以别卷了，工作是做不完的。

过早优化效应 (Premature Optimization Effect)

过早优化是万恶之源。

普特定律 (Putt’s Law)

技术由两类人主导，一类是纯粹的管理人员，一类是纯粹的技术人员。

里德定律 (Reed’s Law)

大型网络，尤其是社交网络的效用会随着网络的大小呈指数级扩增，规模效应

复杂性守恒定律 (The Law of Conservation of Complexity or Tesler’s Law)

系统中存在着一定程度的复杂性，并且不能减少。

得墨忒耳定律 (The Law of Demeter)

得墨忒耳定律又称最少知识原则，是一条与面向对象语言有关的软件设计原则，只和已知的打交道。

抽象泄漏定律 (The Law of Leaky Abstractions)

在某种程度上，所有非平凡的抽象都是有泄漏的。
过度依赖抽象，加上对底层过程的理解不足，实际上使得问题在某些情况下更加复杂。

帕金森琐碎定理 (The Law of Triviality)

群体将给予更多的时间和注意力来处理琐碎的问题，而不是用来处理严肃而实质性的问题。

Unix 哲学 (The Unix Philosophy)

软件组件应该很小，并专注于做一件特定的事情。将小而简单以及定义良好的单元组合在一起，而不是使用大而复杂的多用途程序，可以更轻松地构建系统。

Spotify 模型 (The Spotify Model)

团队围绕功能而非技术进行组织。

沃德勒定律 (Wadler’s Law)

任何语言设计中，讨论下面列表中某个要素所花费的总时间与其位置成正比。

语义 (Semantics)
语法 (Syntax)
词法 (Lexical syntax)
注释语法 (Lexical syntax of comments)
简而言之，在语义上花费一个小时，就要在注释语法上花费八个小时

惠顿定律 (Wheaton’s Law)

不要像个傻子一样。

原则

原则通常是与设计相关的准则。

乔治·伯克斯定律 (All Models Are Wrong or George Box’s Law)

这一原则表明，所有的系统模型都是有缺陷的，但只要它们没有太多缺陷，那便有可能是有用的。这一原则源于统计学，同时也适用于科学和计算模型。

切斯特森围栏 (Chesterson’s Fence)

在了解现有情况背后的原因之前，不应该进行改进。

死海效应 (The Dead Sea Effect)

死海效应表明，在任何一个组织中，工程师的技能、才华和效能往往与他们在公司的时间呈反比。

呆伯特法则 (The Dilbert Principle)

公司会倾向于系统地将工作能力差的员工提升到管理层，以使他们脱离工作流程（在国内目前没有）。

帕累托法则 (The Pareto Principle or The 80/20 Rule)

生活中大多数事情不是均匀分布的。
这个原则也被称为二八法则，重要的少数法则和因素稀疏原则。

舍基原理 (The Shirky Principle)

各机构会努力保留他们能够解决的问题。
当一个人不理解自己的工作就能够获得酬劳时，那么他就很难再去了解这份工作了！

彼得原理 (The Peter Principle)

在等级制度中，人往往会被提升到他们的“无法胜任的水平。

鲁棒性原则 (The Robustness Principle or Postel’s Law)

在自己所做的事情上要保守, 在接受别人的事情上要自由。

SOLID

S：单一功能原则：有且有一个单一的功能，并且该功能应该由这个类完全封装起来
O：开闭原则：对于扩展是开放的，但是对于修改是封闭的
L：里氏替换原则：子类可以扩展父类的功能，但不能改变父类原有的功能
I：接口隔离原则：建立单一接口，不要建立庞大臃肿的接口
D：依赖反转原则：不要太多耦合
这些是 Object-Oriented Programming 的关键原则。诸如此类的设计原则能够帮助开发人员构建更易于维护的系统。