该文章翻译自famous-laws-of-software-development，翻译有误的地方欢迎指正。

像其他任何领域一样，软件开发领域中有许多有趣、著名的法则、原理和定律。程序员、开发者、管理者和架构师经常在对话，会议或者聊天中使用它们。在沟通中我们常常倾向于点头表示赞同，而不愿意让对方知道我们从未听过这些定律，诸如布鲁克斯定律（Brook’s law）、摩尔定律（Moore’s law）或者维尔特定律（Wirth‘s law）。

这些定律是那些在软件开发领域有突出贡献的大牛们提出的一些法则、原理或者名言。同时，这些定律十分有趣，有价值，而且它们背后的故事也值得去了解。

在这篇文章中，我将分享在软件开发领域中对于那些最著名和最常使用的定律的看法和解释。

墨菲定律（Murphy’s Law）

这可能是所有定律中最著名的一条了，因为它不仅仅用在软件开发领域中。

If something can go wrong, it will.

凡是可能出错的事，它一定会出错。

推论1：如果它有效，你可能没有写过它。

推论2：咒骂是程序员唯一说流利的语言。

结论：你写了什么，计算机就做什么；而不是你想什么，计算机就做什么。（PS：实践是检验真理的唯一标准）

防御性编程、版本控制、末日场景（僵尸网络攻击）、测试驱动开发（TDD）、指标驱动开发（MDD）等等，这都是一些防止出错的最佳实践。

布鲁克斯定律（Brook’s Law）

大多数程序员都有意或无意中有过布鲁克斯定律的经历，其表述为：

Adding manpower to a late software project makes it later.

在一个已经延期的项目中增加人力资源只会使其更晚。

如果一个项目已经延期，简单的增加人力很大可能会造成更惨重的后果。检查和评估编程效率的水平、软件方法论、技术架构等等，都是会有很好的收益。如果没有得到期望的结果，可能侯世达定律也在起作用。

侯世达定律（Hofstadter’s Law）

侯世达定律是以Douglas Hofstadter的名字来命名的。该定律可能与生活大爆炸中Leonard Hofstadter产生混淆，即使他说的话对你们某些人也很有道理。

侯世达定律表述为：

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。

侯世达定律指完成复杂任务需要花费的时间总是很难预计的。其自指的特征反映了即便意识到任务的复杂性，预计花费的时间仍是困难的。

这就是为什么在你做出任何估计之前都要留有一些缓冲时间。如果你想了解更多关于如何更好地进行预估，请看我的另一篇文章：Estimation Wizardry。

康威定律（Conway’s Law）

Any piece of software reflects the organizational structure that produced it.

任何软件都能反映出设计它的组织架构。

换句话说：

Organizations which design systems are constrained to produce designs which are copies of the communication structure of these organizations.

设计系统的架构受制于产生这些设计的组织的沟通结构。

在许多组织中，团队都是根据他们的职能进行划分。所以，你们会有前端、后端、数据库团队。简单的说，如果有人想改变一些其他人负责的东西，这对于他来说很难。

一个比较好的方式是通过围绕有界限的上下文来打造团队。例如对微服务架构来说，他们的团队根据业务边界而不是固有的技术架构来做分解。

如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系，那么项目将会遇到麻烦。因此，应该确保组织结构兼容于产品架构。

–《敏捷软件开发的组织模式》

伯斯塔尔定律（Postel’s Law aka Robustness principle）

Be conservative in what you send, be liberal in what you accept.

输出信息时要严谨，接收信息时要宽松。（PS：严于律己，宽以待人）

Jon Postel最初通过实现TCP协议的鲁棒性而阐明这一定律的。这一定律也体现在HTML中，它的成功或者失败取决于你请求何种属性值。

帕累托法则（Pareto Principle aka 80-20 rule）

其也成为80/20法则。

For many phenomena, 80% of consequences stem from 20% of the causes.

对于大多数现象来说，20%的变因操纵着80%的局面。

这个法则揭示一个残酷的事实，80%的bug来自于20%的代码。

另一种陈述为，在一个公司中20%的员工做了80%的工作。问题的关键在于你对于那20%是什么不清楚。

彼得原理（The Peter Principle）

如果你有第一手经验的话，就知道这是一个非常压抑，有时令人沮丧的定律。

In a hierarchy, every employee tends to rise to his level of incompetence.

在等级制定中，每个员工会被擢升到他所不能胜任的职位。

看下面的漫画，你也许会得到一些启示。

柯克霍夫原则（Kerchkhoff’s Principle）

In cryptography, a system should be secure even if everything about the system, except for a small piece of information - the key - is public knowledge.

即使密码系统的任何细节都被人所知，只要密钥未泄露，那么该系统就是安全的。

这是公开密钥密码学中最主要的原则。

林纳斯定律（Linus’s Law）

以 Linus Torvalds —— linux的作者，命名，该原则为：

Given enough eyeballs, all bugs are shallow.

足够多的眼睛，就可让所有问题浮现。

著名的《大教堂与集市》，描述了这一定律。它解释了两种不同的软件开发模式的不同：

  • 大教堂模式，源代码将在软件发行之后公开，但是在每个版本代码开发中严格受限于一个专有的软件开发团队。

  • 集市模式，代码在开发过程中即在互联网公开，供人审阅。

结论是，源代码越广泛地被公开测试、审查和实验，各种形式的bug将被越快的发现。

摩尔定律（Moore’s Law）

The power of computer per unit cost doubles every 24 months.

计算机的性能每两年提升一倍。

更为为人所知的版本是：

The number of transistors on an integrated circuit will double in about 18 months.

集成电路上可容纳的晶体管数目，每18个月便会增加一倍。

或者如下：

The processing speed of computers will double every two years.

计算机的处理速度，每两年便会提升一倍。

维尔特定律（Wirth’s law）

Software gets slower faster than hardware gets faster.

程序变慢的速度快过硬件变快的速度。

该定律与摩尔定律相对立。

90-90法则（Ninety-ninety rule）

The first 90% of the code takes 10% of the time. The remain 10% takes the other 90% of the time.（from original text）

根据维基百科的描述：

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

（开发软件时）前90%的代码要花费90%的开发时间，剩余的10%的代码要再花费90%的开发时间。

Knuth’s optimization principle

Premature optimization is the root of all evil.

过早的优化是罪恶之源。

首先，你需要写出代码，然后找到它的瓶颈，最后针对它进行优化。

诺威格定理（Norvig’s Law）

Any technology that surpasses 50% penetration will never double again (in any number of months).

任何使用率超过50%的技术不会再翻番（在接下来的时间里）。