99%的程序员认不全的软件开发定律

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

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

在这篇文章中，我将分享我对软件开发领域最著名和最常见的定律的解释和想法。

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

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

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

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

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

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

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

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

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

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

当然，不要将这个定律与电视剧《大爆炸》里的 Leonard Hofstadter 混淆起来了，尽管他说的一些话对某些人来说是有一点意义的。

这个定律指出：

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

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

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

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

或者说得更清楚一点：

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

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

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

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

保守输出，自由输入。

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

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

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

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

这是一个相当令人沮丧的定律，特别是如果你碰巧亲身经历过。

在一个等级制度中，每个员工都倾向于晋升到他无法胜任的职位。

呆伯特（Dilbert）系列漫画中有一些这方面的例子。

在密码学中，系统应该是安全的，即使系统的所有东西都是公开的——除了一小部分信息——秘钥。

这是公钥密码学的主要法则。

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

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

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

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

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

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

单位成本的计算机算力每 24 个月翻一番。

最流行的版本是说：

集成电路上的晶体管数量大约每 18 个月会增加一倍。

或者：

计算机的处理速度每两年翻一番！

软件比硬件更容易变慢。

参考一下摩尔定律吧！

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

有人不同意这个的吗？

过早优化是万恶之源。

先写代码，然后找出瓶颈，最后才修复！

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

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

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

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