开发六大定律，比如项目总会延期

前几天在极客时间上看到这个六大定律，说得真是贴切，我来重新解读一下。

与其他领域一样，软件开发领域有很多非常有趣的定律，这些定律有的包括了一些法则，有的则是一些技术大师的名句，每个定律背后都有令人惊叹的背景故事。比如：

1、墨菲定律（Murphy’s Law）

星际穿越男主人公的女儿就叫墨菲，她一直不开心，因为墨菲定律代表了坏运气。如果事情可能出错，它最终一定会出错。这个在软件开发过程中太常见了。评审和设计的时候，我们考虑到了一个隐患，觉得不会出问题吧，最终上线后，那个地方一定会出问题。

有时候 bug 无法在测试环境复现，我们会想当然得认为这可能是个偶然现象，但最终墨菲定律起作用了，生产环境会通过重复出现提醒你，还没有找到问题所在哦。

这是个让研发人员头疼的定律。

2、布鲁克定律（Brook’s Law）

该定律指出：为已经延期的软件项目增加人手只会让项目延期得更厉害。

我记得某电商公司在出问题的时候，大哥说要增加三倍服务器几倍人手，能解决问题吗？不变得更糟就得谢天谢地了。

如果一个项目出现了延期，只是简单地增加人手，最大的可能是带来灾难性的后果。大部分延期都不是因为人员不够引起的，而是编程效率差、软件开发方法陈旧、选错技术架构、需求膨胀等因素引起的。

即使这些都对了，但项目依然可能延期，这说明霍夫施塔特定律在起作用。

3、霍夫施塔特定律（Hofstadter’s Law）

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

这个定律完美的说明了准确预估完成复杂任务所需时间是一件多么难的事……影响因素太多了，历史经验不可复用，人员变化，需求变更，程序员天生乐观等等，都让估算工期变得极其困难。这个定律具有递归性，反映了预估复杂项目的难度，尽管你可能已经做出了最大的努力，而且也知道任务的复杂性，但就是会延误。

人生啊……

4、康威定律（Conway’s Law）

康威定律是马尔文·康威1967年提出的：设计系统的架构受制于产生这些设计的组织的沟通结构。意思是软件的结构反映了开发软件的组织结构。什么样的团队，产生什么样的架构。

比如很多组织就是根据功能性来划分团队的，比如极客时间的研发团队就有大前端开发团队、后端开发团队、测试团队和基础服务团队等等，这些都会对应到软件的功能上。如果有人想要修改的东西属于其他团队，那么他就必须要通过协调的方式去做，否则组织之间就会倾向于局部优化，无法形成有效的合作和闭环。

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

二八原则大家都很熟悉了，对于很多现象，80％的后果源于 20％的原因。还有人说，公司里 80％ 的工作是由 20％ 的员工完成的，问题是你并不清楚是哪 20％员工。你是哪部分呢？

6、摩尔定律（Moore’s Law）

著名的摩尔定律指出，单位成本的计算机算力每 24 个月翻一番。或者，集成电路上的晶体管数量大约每 18 个月会增加一倍。过去几十年互联网的发展，都遵循了这个定律。

你还知道那些软硬件研发领域的定律呢？或者，你经常遭遇哪些定律呢？可以在留言区说说。