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

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

墨菲定律（Murphy's Law）
可能是最著名的定律之一，主要是因为它不仅适用于软件开发。

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

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

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

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

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

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

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

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

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

这个定律指出：

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

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

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

康威定律（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％渗透率的技术都不会再次翻倍（无论在多少个月内）。

破碎的窗户会招致破坏，因此很快所有窗户都被打破。一般来说：混乱会招致更多的混乱。

在软件开发中，我们可以将其应用于代码质量：我们引入代码库的每一种代码异味都会降低我们添加更多代码异味的门槛。我们应该 [[Start Clean]] 并保持代码库干净以避免这种情况发生。许多代码库如此难以理解和维护的原因是，破窗已经悄然出现并且没有足够快地修复。

哲学剃刀是一种通过消除（或“削除”）不太可能的假设来帮助解释某些事情的原则。奥卡姆剃刀表示，如果有多个假设，我们应该选择假设条件最少的假设（这很可能是解释最简单的假设）。

邓宁-克鲁格效应表明，没有经验的人往往会高估自己的能力，而有经验的人往往会低估自己的能力。

如果你不擅长某件事，你会认为你擅长它。如果你擅长某事，你认为你不擅长 - 这可能导致冒名顶替综合症，这让你怀疑自己的能力，以至于你在其他具有相似技能的人中感到不舒服 （害怕别人认为你说的不正确）。

意识到这种认知偏差已经是朝着正确方向迈出的良好一步。它将帮助您更好地评估自己的技能，以便您可以寻求帮助，或者克服自我怀疑并自己行动。

有助于消除邓宁-克鲁格效应和冒名顶替综合症的一种做法是结对或群体编程。你不是独自工作，沉浸在自我怀疑或优越感中，而是与其他人密切合作，边工作边交流思想、学习和教学。

帕金森定律指出，工作总是会填满分配给它的时间。如果您的项目在两周内有截止日期，则该项目将不会在此之前完成。可能需要更长的时间，是的，但绝不会少于我们为它分配的时间，因为我们正在用不必要的工作或拖延来填补时间。

帕金森定律的主要驱动因素是：

• 拖延症（“截止日期太远了，所以我现在不需要匆忙……”）
• 范围蔓延（“当然，我们可以添加这个小功能，它不会花费我们太多时间……”）

为了对抗拖延，我们可以在几天而不是几周或几个月内设定最后期限。比如说在接下来的 2-3 天内需要做什么才能朝着目标前进？一个（健康的！）截止日期可以给我们足够的动力，不要陷入拖延症的低谷。为了防止范围蔓延，我们应该非常清楚地了解我们试图通过项目实现的目标。成功的衡量标准是什么？这个新功能是否会增加这些指标？那么如果每个人都明白这项工作需要更长的时间，我们应该添加它。如果新功能与使命宣言不匹配，请抛弃它。

Kerchkhoff 的原则指出，加密系统应该是安全的，即使它的加密方法是公开的。只有您用来解密某些东西的密钥才需要是私有的。

这很简单，真的。永远不要相信要求其加密方法是私密的加密系统。这被称为“默默无闻的安全”。像这样的系统本质上是不安全的。一旦该加密方法向公众公开，它就容易受到攻击。

Donald Knuth 在他的一部作品中写了“过早优化是万恶之源”这句话，这句话经常断章取意，并被用作根本不关心优化代码的借口。

根据 Knuth 定律，我们不应该浪费精力过早地优化代码。然而，根据沃斯定律，我们也不应该依赖硬件足够快来执行优化不当的代码。最后，这就是我从这些原则中得出的结论：优化可以轻松完成的代码，无需太多努力：例如，编写几行额外代码以避免经历可能包含大量项目的循环。优化一直在执行的关键业务的代码。除此之外，不要在优化代码上花太多精力，除非你已经确定了一个性能瓶颈。

真香定律

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

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

1. https://mp.weixin.qq.com/s/bBAHYLxq9JI6Ew6VRqnlOA - 99%的程序员认不全的软件开发定律
2. https://mp.weixin.qq.com/s/paOO2HiBu2siFYZcszrc-A - 软件开发的规律和原则