摘抄幾個有意思的定律
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我一直認爲溝通本就是很大的成本。