經常使用的軟件開發定律

墨菲定律（Murphy's Law）

多是最著名的定律之一，主要是由於它不只適用於軟件開發。
若是事情可能出錯，它就會出錯。
第一個推論：那些有效的（代碼），你可能反而沒有寫出來。
第二個推論：詛咒是惟一一門全部程序員都能流利說出來的語言。
結論：電腦會按照你所寫的（代碼）去作，而不是按照你所想的去作。
防護性編程、版本控制、末日場景（針對那些該死的殭屍服務器攻擊）、TDD、MDD，等等，這些都是針對這必定律的防護性實踐。

 

布魯克定律（Brook's Law）

大多數開發人員都有意無心地經歷過布魯克定律，該定律指出：
爲已經延期的軟件項目增長人手只會讓項目延期得更厲害。
若是一個項目出現了延期，只是簡單地增長人手極可能會帶來災難性的後果。對編程效率、軟件開發方法、技術架構等因素進行評審老是會帶來更好的結果。若是沒有，那說明霍夫施塔特定律也在起做用。

 

霍夫施塔特定律（Hofstadter's Law）

這個定律指出：
即便你考慮到了霍夫施塔特定律，項目的實際完成時間老是比預期的要長。
這個「定律」是關於準確預估完成複雜任務所需時間的難度。這個定律具備遞歸性，反映了預估複雜項目的難度，儘管你可能已經作出了最大的努力，並且也知道任務的複雜性。
這就是爲何在進行項目預估時必需要有一個緩衝區。

 

康威定律（Conway’s Law）

軟件的結構反映了開發軟件的組織的結構。
或者說得更清楚一點：
組織所設計的系統的結構受限於組織的通訊結構。
不少組織是根據功能性技能來劃分團隊的，因此會有前端開發團隊、後端開發團隊和數據庫開發團隊。簡單地說，若是某人想要改變的東西屬於其餘人，那麼他就很難改變這些東西。
如今愈來愈多的組織根據有界上下文來組建團隊，而微服務等架構也在根據服務邊界而不是孤立的技術架構分區來組建團隊。
所以，根據目標軟件架構來組建團隊能夠更容易實現軟件架構，而這就是對抗康威法律的一種有效方式。

 

波斯托定律（Postel's Law）或魯棒性法則

保守輸出，自由輸入。
Jon Postel 最初將它做爲實現健壯的 TCP 的一個原則。這個原則也體如今 HTML 中，HTML 的成敗能夠歸因於它的不少屬性，但究竟 HTML 是成功的仍是失敗的，不一樣的人有不一樣的見解。

 

帕累托法則（Pareto Principle）或 80/20 法則

對於不少現象，80％的後果源於 20％的緣由。
80％的 bug 來自 20％的代碼，這個說的就是帕累托法則。
還有人說，公司裏 80％的工做是由 20％的員工完成的，問題是你並不清楚是哪 20％員工。

 

彼得法則（The Peter Principle）

這是一個至關使人沮喪的定律，特別是若是你碰巧親身經歷過。
在一個等級制度中，每一個員工都傾向於晉升到他沒法勝任的職位。
呆伯特（Dilbert）系列漫畫中有一些這方面的例子。

基爾霍夫法則（Kerchkhoff's Principle）

在密碼學中，系統應該是安全的，即便系統的全部東西都是公開的——除了一小部分信息——祕鑰。
這是公鑰密碼學的主要法則。

 

萊納斯定律（Linus's Law）

這是以 Linux 之父 Linus Torvalds 的名字命名的，該定律指出：
若是有足夠多的眼睛，全部的 bug 都將無所遁形。
可使用著名的《大教堂與集市》來描述這個定律，它解釋了兩種不一樣的自由軟件開發模型之間的對比：
大教堂模型——每一個軟件發行版都提供源代碼，但發行版之間的代碼開發僅限於一組專有的軟件開發人員。
集市模型——代碼開發經過互聯網公開進行。
結論？對源代碼進行更普遍的公開測試、評審和實驗，就會更快地發現各類形式的 bug。

 

摩爾定律（Moore's Law）

單位成本的計算機算力每 24 個月翻一番。
最流行的版本是說：
集成電路上的晶體管數量大約每 18 個月會增長一倍。
或者：
計算機的處理速度每兩年翻一番！

 

沃斯定律（Wirth's Law）

軟件比硬件更容易變慢。
參考一下摩爾定律吧！

 

九九法則（Ninety-Ninety Rule）

前 90％的代碼佔用了 10％的時間，其他的 10％代碼佔用了剩下的 90％時間。
有人不一樣意這個的嗎？

 

克努特優化法則（Knuth's Optimization Principle）

過早優化是萬惡之源。
先寫代碼，而後找出瓶頸，最後才修復！

 

諾維格定律（Norvig's Law）

任何超過 50％滲透率的技術都不會再次翻倍（不管在多少個月內）。

 

真香定律別更新了，我學不動了！……真香。全部程序員都逃不過的定律，贊成嗎？