当程序员谈论开发设计时，常常会聊到非常多的定律，而Github上的一个名为「hacker-laws」的仓库收录了一些最常见的定律、原则等，获得了16.3k的Star。

还记得所有AI教程必提的「奥卡姆剃刀原则」吗？即：如无必要，勿增实体。这条原则也被收藏，还有一些不太常见的费茨法则、盖尔定律、康威定律等，都被一一收入囊中。

写代码累了困了？这些法则让工作事半功倍

90-9-1法则（1%法则）

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

现实世界的例子：2014 年，对四个健康的数字社交网络进行的一项研究发现，排名前 1% 的人创造了 73% 的帖子，紧随其后的 9% 平均占 25%，其余的 90% 的人平均占 2%。

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

技术成熟度曲线法则

技术成熟度曲线是高德纳咨询公司对技术最初兴起和发展的视觉展现。一图胜千言：

简而言之，这个曲线表明，新技术及其潜在影响通常会引发一轮浪潮。团队快速使用这些新技术，但有时会对结果感到失望，这可能是因为该技术还不够成熟，或者现实应用还没有完全实现。

经过一段时间后，技术的能力提高了，使用它的实际机会会增加，最终团队也可以提高工作效率。

罗伊·阿马拉简洁地总结了这一点：我们倾向于高估技术短期内的影响，并低估其长期效应。

破窗效应

在破窗理论中认为，一些明显的犯罪迹象(或缺乏环保意识)会导致进一步的、更严重的犯罪(或环境的进一步恶化)。

破窗理论已应用于软件开发中，它表明劣质代码可能会影响后续优化的效率，从而进一步造成代码劣化；随着时间的推移，这种效应将会导致代码质量大幅下降。

没那么常见的法则，但也暗藏工作秘诀

阿姆达尔定律

阿姆达尔定律是一个显示计算任务潜在加速能力的公式。这种能力可以通过增加系统资源来实现，通常用于并行计算中。

它可以预测增加处理器数量的实际好处，然而增加处理器数量会受到程序并行性的限制。

举例说明：如果程序由两部分组成，A部分必须由单个处理器执行，B部分可以并行运行。那么向执行程序的系统添加多个处理器只能获得有限的好处。

它可以极大地提升部分 B 的运行速度，但部分 A 的运行速度将保持不变。

下图展示了一些运行速度的提升潜能的例子：

可以看出，50％ 并行化的程序在使用大于 10 个处理单元之后的速度提升收效甚微，而 95％ 并行化的程序在使用超过一千个处理单元之后仍然可以显著提升速度。

随着摩尔定律逐渐失效，单个处理器的速度增加缓慢，并行化是提高性能的关键。

图形编程是一个极好的例子，现代着色器可以并行渲染单个像素或片段。这也是现代显卡通常具有数千个处理核心（GPU 单元）的原因。

德墨忒尔定律

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

该定律表明，软件的一个单元应该只与其直接合作者交谈。

比如对象 A 引用了对象 B，对象 B 引用了对象 C，则 A 可以直接调用 B 的方法，但不应直接调用 C 的方法。所以如果 C 有一个 dothing() 的方法，A 不应该直接调用，而是用 B.getC().doThis()。

遵循这一定律可以限制代码更改的范围，使其以后更容易维护、更安全。

坎宁汉姆定律

在网络上想得到正确答案的最好方法不是提问题，而是发布一个错误的答案。

除了以上的这些法则，该仓库还给出了很多的原则。

职场相关原则

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

能力强的人更有可能离开，能力差的人反而会留下。

呆伯特原则：公司会倾向于系统地将工作能力差的员工提升到管理层，以使他们脱离工作流程。

技术相关的原则：

单一功能原则：每个模块或者类只应该有一项功能。

开闭原则：实体应开放扩展并关闭修改。

里氏替换原则：可以在不破坏系统的情况下，用子类型替换类型。

接口隔离原则：不应强制任何客户端依赖于它不使用的方法。

依赖翻转原则：高级模块不应该依赖于低级实现。

还有一些具有哲学意味的原则：

鲁棒性原则：在自己所做的事情上要保守, 在接受别人的事情上要自由。

你不需要它法则：只有当你需要某些东西的时候，才去实现它们，而不是在你预见的时候。

KISS原则：保持简单和直白。

还有很多的法则和原则没有一一指出，需要的小伙伴请点击下面的链接打开查看。

参考链接：

https://github.com/nusr/hacker-laws-zh