開發六大定律，比如專案總會延期
前幾天在極客時間上看到這個六大定律，說得真是貼切，我來重新解讀一下。
與其他領域一樣，軟體開發領域有很多非常有趣的定律，這些定律有的包括了一些法則，有的則是一些技術大師的名句，每個定律背後都有令人驚歎的背景故事。比如：
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 個月會增加一倍。過去幾十年網際網路的發展，都遵循了這個定律。
你還知道那些軟硬體研發領域的定律呢？或者，你經常遭遇哪些定律呢？可以在留言區說說。