必须知道的八个定律（帮你整理归纳生活中）
必须知道的八个定律（帮你整理归纳生活中）凡是可能出错，就一定出错。指的是任何一个事件，只要具有大于零的概率，就可以确定它可以发生。该法则警示我们平时对测试中和生产环境中的小问题都不可忽视，不能放过任何一个小的问题，而且越是平时不被关注的边缘系统越容易出问题。我们常说一切问题皆是人的问题，所以在平时我们还要注重人的自身素质提高的培养。干任何事情先梳理出20%的功能，而这些功能往往恰好是“黄金”功能。比如在软件开发领域，在代码中也是约20%的核心代码逻辑支撑了整个系统的运转。“每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆及1000起事故隐患”该法则强调两点:a.事故的发生是量的积累的结果；b.再好的技术、再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。
“以道统术，以术得道”，对我们在生活或工作中经常用的“术”进行总结、归纳，就有了“道”的东西。基于这些“道”（定律法则），内功与招式齐修，可以指导我们如何更好的工作、如何提升效率、如何有意识的风险管控。
下面列举一些对我们的生活与工作很有指导与实践意义的定律法则。
黄金法则
- 二八定律
在任何一组事物中，最重要的只占其中一小部分，约20%。其余80%尽管是多数，却是次要的。
干任何事情先梳理出20%的功能，而这些功能往往恰好是“黄金”功能。比如在软件开发领域，在代码中也是约20%的核心代码逻辑支撑了整个系统的运转。
- 海恩法则
“每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆及1000起事故隐患”
该法则强调两点:a.事故的发生是量的积累的结果；b.再好的技术、再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。
该法则警示我们平时对测试中和生产环境中的小问题都不可忽视，不能放过任何一个小的问题，而且越是平时不被关注的边缘系统越容易出问题。我们常说一切问题皆是人的问题，所以在平时我们还要注重人的自身素质提高的培养。
- 墨菲定律（Murphy's Law）
凡是可能出错，就一定出错。指的是任何一个事件，只要具有大于零的概率，就可以确定它可以发生。
凡是我们怀疑的生产线上（系统薄弱点），都要拿出来仔细过一遍，绝不能轻易放过一丝一毫的怀疑，避免因疏忽遗漏导致实际生产中重大事故的发生。
- 布鲁克定律（Brook's Law）
为已经延期的工程（软件）项目增加人手只会让项目延期得更厉害。
- 霍夫施塔特定律（Hofstadter's Law）
开发所需时间，往往比你预期的要长。哪怕你考虑了这条定律，所需时间依旧会超过你的预期。
- 霍夫施塔特定律（Hofstadter's Law）
原本是指官僚主义，后来指开发计划中，部分人认为在开发初期效率低下，后期在截止日期接近后疯狂赶进度，从而经常不能在预计日期内完工。
如果和上一条定律结合，那就会得出一个非常悲观的理论，即哪怕拼命加班996/007.依旧很可能不能及时完工。
- 康威定律（Conway’s Law）
软件的结构反映了开发软件的组织的结构。换言之，有什么样的团队结构就产生什么样的技术架构。
举例软件开发领域，一个集中式的开发者团队会开发出各组件耦合的整体应用。相反，分布式的团队会开发出单独的(微)服务，每一部分关注点分离，职责明确。
经常提的工程模块化，还有在全球有大量独立开发者的开源项目，通常是模块化和可重用库，这就是很有说服力的例子。
如今，强大的集成应用解耦成微服务已成趋势。这很棒，因为这可以加速交付使用项目。但你也应该牢记 Conway定律，在公司组织构建中投入与技术开发同样多的工作。
- 波斯托定律（Postel's Law）或鲁棒性法则
自由输入，保守输出。鲁棒是Robust的音译，也就是健壮和强壮的意思。
它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持其它某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。
- 莱纳斯定律（Linus's Law）
如果有足够多的眼睛，所有的 bug 都将无所遁形。
- 摩尔定律（Moore's Law）
单位成本的计算机算力每 24 个月翻一番。当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。换言之，每一美元所能买到的电脑性能，将每隔18-24个月翻一倍以上。这一定律揭示了信息技术进步的速度。
很多领域科学家以及产业分析师们认为摩尔定律已失效，但也有人反对。有业内人士担心，如果摩尔定律真的失效，半导体行业的发展放缓将影响整个科技行业推进。
- 沃斯定律（Wirth's Law）
软件比硬件更容易变慢。
- 诺维格定律（Norvig's Law）
“当公司的市场占有率>50% ，市场占有率无法再翻番了”。这句话由谷歌研究院院长诺威格（Norvig）提出，被誉为诺威格定理或诺威格定律（Norvig's Law）。同时被一些人认定为与摩尔定律、安迪-比尔定律并称的IT产业三大定律。
- 安迪-比尔定律（Andy and Bill’s Law）
原话是 “Andy gives Bill takes away.（安迪提供什么，比尔拿走什么。）” 安迪指英特尔前CEO安迪·格鲁夫，比尔指微软前任CEO比尔·盖茨，这句话的意思是，硬件提高的性能，很快被软件消耗掉了。
虽然用户很是烦恼新的软件把硬件提升所带来的好处几乎全部用光，但是在 IT 领域，各个硬件厂商恰恰是靠软件开发商用光自己提供的硬件资源得以生存。
- 琐碎定律
该定律认为，在团队协作中更多争论会发生在不重要的细节中，而不是最重大的事情上。
在讨论非常专业而且重大的事情时，一般人由于缺乏专业知识，不敢随便发言，以免失言，贻笑大方，因此多半都会肯定（或逃避）该重大方案，而提些与主题无关的鸡毛蒜皮小事。相对的，对于简单的细节，由于平常大家都会接触到而且有相当的认识，反而意见特别多。
- 真香定律
别更新了，我学不动了！……真香。
- 九九法则（Ninety-Ninety Rule）
前 90％的代码占用了 10％的时间，其余的 10％代码占用了剩下的 90％时间。
- 克努特优化法则（Knuth's Optimization Principle）
过早优化是万恶之源。除非代码开始工作，否则甚至就不要有优化的念头。只有当你必须要优化的时候，才能借助实战数据的帮助。“我们一定要有大局观：过早的优化是万恶之源”——Donald Knuth。
- 帕累托法则（Pareto Principle）或 80/20 法
对于很多现象，80％的后果源于 20％的原因。
- 彼得法则（The Peter Principle）
在一个等级制度中，每个员工都倾向于晋升到他无法胜任的职位。
- 基尔霍夫法则（Kerchkhoff's Principle）
在密码学中，系统应该是安全的，即使系统的所有东西都是公开的——除了一小部分信息——秘钥。
- KISS（Keep it simple stupid!）原则
简单性（避免复杂性）应该永远当作是一个重要的目标。写简单的代码，不但花费的时间少，错误少，而且修改起来也容易。
- 最小惊讶原则
最小惊讶原则通常引用于用户界面方面，但这一原则也适用于编写代码。
代码应该尽可能地不要让阅读者惊讶。遵守标准约定，注释说什么代码就做什么，命名是什么意思代码就是什么意思，尽可能地避免惊讶导致的潜在的负面影响。
- 关注点分离原则
不同的功能区域应该由明显的重叠最小的代码模块进行管理。
- SOLID原则
设计模式中的SOLID原则，分别是单一原则、开闭原则、里氏替换原则、接口隔离原则、依赖倒置原则。前辈们总结出来的，遵循五大原则可以使程序解决紧耦合，更加健壮。
没人写一款程序能完全遵守SOLID原则，甚至有些设计模式是违反SOLID原则。如何权衡就要看利是否大于弊。
- SMART原则
“SMART原则是目标管理中的一种方法，SMART原则中的S M A R T分别对应了五个英文单词Specific(明确) Measurable(可衡量) Achievable(可达成)， Relevant(相关)，和Time-bound(有时限)”。
我们在制定一个架构目标的时候要符合这样的原则：
明确：对一个老系统做架构升级改造，需要目标明确，达到控制和逻辑分离，子系统之间解耦；
可衡量：各个系统上线之后是否会相互影响；
可达成：分离和解耦的目标是一定可以实现的；
相关：比如跟其他系统的边界交互处要考虑的因素都有哪些；
有时限：目标不能无休止进行下去，一定要有一个清晰的完成日期。
讲究术与道
这25条定律法则（原则）只是我们各行各业（尤其是软件）中总结出的教训中一些例子。随着软件开发经验的增长，我们将会学会更多，悟出很多规律。尽管其中某些定律现在看起来是常识，但亲身经历过会认识得更深刻。
“以道统术，以术得道”，基于这些定律法则，内功与招式齐修，才能让我们的功力发挥到极致，从而帮助我们改善编码的组织结构、架构的设计实现与项目的风险管控。
如果你觉得文章对你有用，欢迎点赞和转发，这会让我很开心、很有成就感。
也希望大家关注我，我会不断输出有价值的东西。
