开发商必备！Github上1.6W-star的《BlackMagic》，早知道就不秃了，仓库里收录了一些最常用的规律、原理等，获得了16.3kStars。还记得所有AI教程都必须提到的“奥卡姆剃刀原理”吗？即：如非必要，不增加实体。这个原理也收录了，一些不太常见的菲茨定律，盖尔定律，康威定律等等，都一一收录了。厌倦了写代码？Theserulesmakeworkmoreeffectivewithless90-9-1rule(1%rule)90-9-1规则表明，在wiki等互联网社区中，90%的用户只阅读内容，不参与互动，并且9%的用户会参与讨论，而只有1%的用户创建内容。真实世界的例子：2014年对四个健康数字社交网络的一项研究发现，前1%的人创造了73%的帖子，接下来的9%平均创造了25%，其余90%的人平均创造了2%。同样，帕累托法则指出，生活中的大多数事情并不是均匀分布的。该原则也称为80/20规则、重要少数规则和因子稀疏原则。技术炒作周期炒作周期是Gartner对一项技术最初兴起和发展的直观表示。一图胜千言：简而言之，这条曲线表明新技术及其潜在影响往往会掀起波澜。团队快速使用这些新技术，但有时对结果感到失望，可能是因为技术还不够成熟，或者现实世界的应用还没有完全实现。随着时间的推移，随着技术能力的提高，实际使用它的机会也会增加，最终团队会变得更有效率。罗伊·阿马拉(RoyAmara)简洁地总结道：我们倾向于高估技术在短期内的影响，而低估其长期影响。破窗效应在破窗理论中，一些明显的犯罪迹象（或缺乏环保意识）会导致更严重的犯罪（或环境进一步恶化）。破窗理论已经应用到软件开发中，表明不良代码可能会影响后续优化的效率，导致代码进一步退化；随着时间的推移，这种影响将导致代码质量显着下降。一个不太常见的定律，但也是一个隐藏的秘密Amdahl定律Amdahl定律是一个显示计算任务潜在加速的公式。这种能力可以通过增加系统资源来实现，通常用于并行计算。它预测了增加处理器数量的真正好处，但是增加处理器数量受到程序并行性的限制。举例说明：如果一个程序由两部分组成，A部分必须由单个处理器执行，B部分可以并行运行。将多个处理器添加到执行程序的系统中只会产生有限的好处。它可以大大加快B部分的运行速度，但A部分的运行速度将保持不变。下图展示了一些加速潜力的例子：可以看出，50%并行化的程序在使用了10个以上的处理单元后速度提升不大，而95%并行化的程序使用了1000个以上的处理单元。1个处理单元后，速度仍可明显提升。随着摩尔定律的失效和单个处理器速度的缓慢增加，并行化是提高性能的关键。图形编程是一个很好的例子，现代着色器可以并行渲染单个像素或片段。这就是现代图形卡通常具有数千个处理核心（GPU单元）的原因。得墨忒耳法则得墨忒耳法则又称最少知识原则，是与面向对象语言相关的软件设计原则。该法则规定，一个软件单元只能与其直接合作者对话。比如对象A引用对象B，对象B引用对象C，那么A可以直接调用B的方法，但是不应该直接调用C的方法。所以如果C有一个dothing()方法，A不应该直接调用它，而是使用B.getC().doThis()。遵循这个规律限制了代码修改的范围，使得以后维护起来更容易，也更安全。坎宁安定律在Internet上获得正确答案的最佳方法不是提出问题，而是发布错误答案。除了以上规则，仓库还给出了很多原则。工作场所相关原则死海效应原则：在任何组织中，工程师的技能、才能和效率往往与他们在公司的时间成反比。能力强的人更容易离开，而能力差的人则留下来。呆伯特原则：公司倾向于系统地将表现不佳的人提拔到管理层，以将他们排除在工作流程之外。技术相关原则：单一功能原则：每个模块或类应该只有一个功能。开闭原则：实体应该对扩展开放，对修改关闭。Liskov替换原则：类型可以被子类型替换而不会破坏系统。接口隔离原则：不应强迫客户端依赖于它不使用的方法。依赖倒置原则：高层模块不应该依赖于低层实现。还有哲学趣味原则：稳健性原则：做事要保守，接受别人的要开明。你不需要它法则：只有在你需要的时候才去做某事，而不是在你预见到它的时候。KISS原则：保持简单明了。还有很多规则和原则没有一一指出。需要的朋友请点击下方链接打开查看。参考链接：https://github.com/nusr/hacker-laws-zh
