几个有意思的定理

摘抄几个有意思的定律

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

偶然发生的bug在线上一定会发生

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

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

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

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

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

人生啊……

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

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

5、阿姆达尔定律

该定律是指：系统中对某一部件采用更快执行方式所能获得的系统性能改进程度，取决于这种执行方式被使用的频率，或所占总执行时间的比例。阿姆达尔定律实际上定义了采取增强（加速）某部分功能处理的措施后可获得的性能改进或执行时间的加速比。简单来说是通过更快的处理器来获得加速是由慢的系统组件所限制。

阿姆达尔曾致力于并行处理系统的研究。对于固定负载情况下描述并行处理效果的加速比s，阿姆达尔经过深入研究给出了如下公式：

S=1/(1-a+a/n)

其中，a为并行计算部分所占比例，n为并行处理结点个数。这样，当1-a=0时，(即没有串行，只有并行)最大加速比s=n；当a=0时（即只有串行，没有并行），最小加速比s=1；当n→∞时，极限加速比s→ 1/（1-a），这也就是加速比的上限。例如，若串行代码占整个代码的25%，则并行处理的总体性能不可能超过4。这一公式已被学术界所接受，并被称做“阿姆达尔定律”，也称为“安达尔定理”(Amdahl law)。

个人对1，2，3感觉比较深刻，对4我一直认为沟通本就是很大的成本。