与其他领域一样，软件开发领域也有一些非常有趣的定律。程序员、技术经理和架构师们经常在会议和聊天中提到它们。作为小白，我们常常只有点头附和的份，因为我们不希望让对方知道我们实际上根本不知道布鲁克、摩尔或者维斯都是什么人。

这些定律包括了一些法则或软件开发大神的名言。它们都很有趣，值得我们一探究竟，而且每个定律背后都有令人惊叹的背景故事。

​

墨菲定律（Murphy's Law）

可能是最著名的定律之一，主要是因为它不仅适用于软件开发。

如果事情可能出错，它就会出错。

第一个推论：那些有效的（代码），你可能反而没有写出来。

第二个推论：诅咒是唯一一门所有程序员都能流利说出来的语言。

结论：电脑会按照你所写的（代码）去做，而不是按照你所想的去做。

防御性编程、版本控制、末日场景（针对那些该死的僵尸服务器攻击）、TDD、MDD，等等，这些都是针对这一定律的防御性实践。

布鲁克定律（Brook's Law）

大多数开发人员都有意无意地经历过布鲁克定律，该定律指出：

为已经延期的软件项目增加人手只会让项目延期得更厉害。

如果一个项目出现了延期，只是简单地增加人手很可能会带来灾难性的后果。对编程效率、软件开发方法、技术架构等因素进行评审总是会带来更好的结果。如果没有，那说明霍夫施塔特定律也在起作用。

​

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

霍夫施塔特定律由 Douglas Hofstadter 提出，并以他的名字命名。

这个定律指出：

即使你考虑到了霍夫施塔特定律，项目的实际完成时间总是比预期的要长。

这个“定律”是关于准确预估完成复杂任务所需时间的难度。这个定律具有递归性，反映了预估复杂项目的难度，尽管你可能已经做出了最大的努力，而且也知道任务的复杂性。

这就是为什么在进行项目预估时必须要有一个缓冲区。

小编整理了一份零基础与进阶web前端学习资料，web 前端技术学习裙，9567，66604，收取视频资料工具，获取源码！

​

康威定律（Conway’s Law）

软件的结构反映了开发软件的组织的结构。

或者说得更清楚一点：

组织所设计的系统的结构受限于组织的通信结构。

很多组织是根据功能性技能来划分团队的，所以会有前端开发团队、后端开发团队和数据库开发团队。简单地说，如果某人想要改变的东西属于其他人，那么他就很难改变这些东西。

现在越来越多的组织根据有界上下文来组建团队，而微服务等架构也在根据服务边界而不是孤立的技术架构分区来组建团队。

因此，根据目标软件架构来组建团队可以更容易实现软件架构，而这就是对抗康威法律的一种有效方式。

​

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

保守输出，自由输入。

Jon Postel 最初将它作为实现健壮的 TCP 的一个原则。这个原则也体现在 HTML 中，HTML 的成败可以归因于它的很多属性，但究竟 HTML 是成功的还是失败的，不同的人有不同的看法。

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

对于很多现象，80％的后果源于 20％的原因。

80％的 bug 来自 20％的代码，这个说的就是帕累托法则。

还有人说，公司里 80％的工作是由 20％的员工完成的，问题是你并不清楚是哪 20％员工。

​

莱纳斯定律（Linus's Law）

这是以 Linux 之父 Linus Torvalds 的名字命名的，该定律指出：

如果有足够多的眼睛，所有的 bug 都将无所遁形。

可以使用著名的《大教堂与集市》来描述这个定律，它解释了两种不同的自由软件开发模型之间的对比：

大教堂模型——每个软件发行版都提供源代码，但发行版之间的代码开发仅限于一组专有的软件开发人员。

集市模型——代码开发通过互联网公开进行。

结论：对源代码进行更广泛的公开测试、评审和实验，就会更快地发现各种形式的 bug。

九九法则（Ninety-Ninety Rule）

前 90％的代码占用了 10％的时间，其余的 10％代码占用了剩下的 90％时间。

真香定律

别更新了，我学不动了！……真香。

所有程序员都逃不过的定律，同意吗？

以上软件开发定律，你都知道几条？你还知道有哪些软件开发的黄金定律吗？欢迎留言！

​