经常使用的软件开发定律

墨菲定律（Murphy's Law）

多是最著名的定律之一，主要是由于它不只适用于软件开发。
若是事情可能出错，它就会出错。
第一个推论：那些有效的（代码），你可能反而没有写出来。
第二个推论：诅咒是惟一一门全部程序员都能流利说出来的语言。
结论：电脑会按照你所写的（代码）去作，而不是按照你所想的去作。
防护性编程、版本控制、末日场景（针对那些该死的僵尸服务器攻击）、TDD、MDD，等等，这些都是针对这必定律的防护性实践。

 

布鲁克定律（Brook's Law）

大多数开发人员都有意无心地经历过布鲁克定律，该定律指出：
为已经延期的软件项目增长人手只会让项目延期得更厉害。
若是一个项目出现了延期，只是简单地增长人手极可能会带来灾难性的后果。对编程效率、软件开发方法、技术架构等因素进行评审老是会带来更好的结果。若是没有，那说明霍夫施塔特定律也在起做用。

 

霍夫施塔特定律（Hofstadter's Law）

这个定律指出：
即便你考虑到了霍夫施塔特定律，项目的实际完成时间老是比预期的要长。
这个“定律”是关于准确预估完成复杂任务所需时间的难度。这个定律具备递归性，反映了预估复杂项目的难度，尽管你可能已经作出了最大的努力，并且也知道任务的复杂性。
这就是为何在进行项目预估时必需要有一个缓冲区。

 

康威定律（Conway’s Law）

软件的结构反映了开发软件的组织的结构。
或者说得更清楚一点：
组织所设计的系统的结构受限于组织的通讯结构。
不少组织是根据功能性技能来划分团队的，因此会有前端开发团队、后端开发团队和数据库开发团队。简单地说，若是某人想要改变的东西属于其余人，那么他就很难改变这些东西。
如今愈来愈多的组织根据有界上下文来组建团队，而微服务等架构也在根据服务边界而不是孤立的技术架构分区来组建团队。
所以，根据目标软件架构来组建团队能够更容易实现软件架构，而这就是对抗康威法律的一种有效方式。

 

波斯托定律（Postel's Law）或鲁棒性法则

保守输出，自由输入。
Jon Postel 最初将它做为实现健壮的 TCP 的一个原则。这个原则也体如今 HTML 中，HTML 的成败能够归因于它的不少属性，但究竟 HTML 是成功的仍是失败的，不一样的人有不一样的见解。

 

帕累托法则（Pareto Principle）或 80/20 法则

对于不少现象，80％的后果源于 20％的缘由。
80％的 bug 来自 20％的代码，这个说的就是帕累托法则。
还有人说，公司里 80％的工做是由 20％的员工完成的，问题是你并不清楚是哪 20％员工。

 

彼得法则（The Peter Principle）

这是一个至关使人沮丧的定律，特别是若是你碰巧亲身经历过。
在一个等级制度中，每一个员工都倾向于晋升到他没法胜任的职位。
呆伯特（Dilbert）系列漫画中有一些这方面的例子。

基尔霍夫法则（Kerchkhoff's Principle）

在密码学中，系统应该是安全的，即便系统的全部东西都是公开的——除了一小部分信息——秘钥。
这是公钥密码学的主要法则。

 

莱纳斯定律（Linus's Law）

这是以 Linux 之父 Linus Torvalds 的名字命名的，该定律指出：
若是有足够多的眼睛，全部的 bug 都将无所遁形。
可使用著名的《大教堂与集市》来描述这个定律，它解释了两种不一样的自由软件开发模型之间的对比：
大教堂模型——每一个软件发行版都提供源代码，但发行版之间的代码开发仅限于一组专有的软件开发人员。
集市模型——代码开发经过互联网公开进行。
结论？对源代码进行更普遍的公开测试、评审和实验，就会更快地发现各类形式的 bug。

 

摩尔定律（Moore's Law）

单位成本的计算机算力每 24 个月翻一番。
最流行的版本是说：
集成电路上的晶体管数量大约每 18 个月会增长一倍。
或者：
计算机的处理速度每两年翻一番！

 

沃斯定律（Wirth's Law）

软件比硬件更容易变慢。
参考一下摩尔定律吧！

 

九九法则（Ninety-Ninety Rule）

前 90％的代码占用了 10％的时间，其他的 10％代码占用了剩下的 90％时间。
有人不一样意这个的吗？

 

克努特优化法则（Knuth's Optimization Principle）

过早优化是万恶之源。
先写代码，而后找出瓶颈，最后才修复！

 

诺维格定律（Norvig's Law）

任何超过 50％渗透率的技术都不会再次翻倍（不管在多少个月内）。

 

真香定律别更新了，我学不动了！……真香。全部程序员都逃不过的定律，赞成吗？