這些著名的軟件開發(fā)定律，你都知道哪些？

與其他領域一樣，軟件開發(fā)領域也有一些非常有趣的定律。程序員、技術經(jīng)理和架構師們經(jīng)常在會議和聊天中提到它們。作為小白，我們常常只有點頭附和的份，因為我們不希望讓對方知道我們實際上根本不知道布魯克、摩爾或者維斯都是什么人。

這些定律包括了一些法則或軟件開發(fā)大神的名言。它們都很有趣，值得我們一探究竟，而且每個定律背后都有令人驚嘆的背景故事。

在這篇文章中，我將分享我對軟件開發(fā)領域最著名和最常見的定律的解釋和想法。

墨菲定律（Murphy's Law）

可能是最著名的定律之一，主要是因為它不僅適用于軟件開發(fā)。

如果事情可能出錯，它就會出錯。

第一個推論：那些有效的（代碼），你可能反而沒有寫出來。

第二個推論：詛咒是唯一一門所有程序員都能流利說出來的語言。

結論：電腦會按照你所寫的（代碼）去做，而不是按照你所想的去做。

防御性編程、版本控制、末日場景（針對那些該死的僵尸服務器攻擊）、TDD、MDD，等等，這些都是針對這一定律的防御性實踐。

布魯克定律（Brook's Law）

大多數(shù)開發(fā)人員都有意無意地經(jīng)歷過布魯克定律，該定律指出：

為已經(jīng)延期的軟件項目增加人手只會讓項目延期得更厲害。

如果一個項目出現(xiàn)了延期，只是簡單地增加人手很可能會帶來災難性的后果。對編程效率、軟件開發(fā)方法、技術架構等因素進行評審總是會帶來更好的結果。如果沒有，那說明霍夫施塔特定律也在起作用。

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

霍夫施塔特定律由 Douglas Hofstadter 提出，并以他的名字命名。

當然，不要將這個定律與電視劇《大爆炸》里的 Leonard Hofstadter 混淆起來了，盡管他說的一些話對某些人來說是有一點意義的。

這個定律指出：

即使你考慮到了霍夫施塔特定律，項目的實際完成時間總是比預期的要長。

這個“定律”是關于準確預估完成復雜任務所需時間的難度。這個定律具有遞歸性，反映了預估復雜項目的難度，盡管你可能已經(jīng)做出了最大的努力，而且也知道任務的復雜性。

這就是為什么在進行項目預估時必須要有一個緩沖區(qū)。

康威定律（Conway’s Law）

軟件的結構反映了開發(fā)軟件的組織的結構。

或者說得更清楚一點：

組織所設計的系統(tǒng)的結構受限于組織的通信結構。

很多組織是根據(jù)功能性技能來劃分團隊的，所以會有前端開發(fā)團隊、后端開發(fā)團隊和數(shù)據(jù)庫開發(fā)團隊。簡單地說，如果某人想要改變的東西屬于其他人，那么他就很難改變這些東西。

現(xiàn)在越來越多的組織根據(jù)有界上下文來組建團隊，而微服務等架構也在根據(jù)服務邊界而不是孤立的技術架構分區(qū)來組建團隊。

因此，根據(jù)目標軟件架構來組建團隊可以更容易實現(xiàn)軟件架構，而這就是對抗康威法律的一種有效方式。

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

保守輸出，自由輸入。

Jon Postel 最初將它作為實現(xiàn)健壯的 TCP 的一個原則。這個原則也體現(xiàn)在 HTML 中，HTML 的成敗可以歸因于它的很多屬性，但究竟 HTML 是成功的還是失敗的，不同的人有不同的看法。

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

對于很多現(xiàn)象，80％的后果源于 20％的原因。

80％的 bug 來自 20％的代碼，這個說的就是帕累托法則。

還有人說，公司里 80％的工作是由 20％的員工完成的，問題是你并不清楚是哪 20％員工。

彼得法則（The Peter Principle）

這是一個相當令人沮喪的定律，特別是如果你碰巧親身經(jīng)歷過。

在一個等級制度中，每個員工都傾向于晉升到他無法勝任的職位。

呆伯特（Dilbert）系列漫畫中有一些這方面的例子。

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

在密碼學中，系統(tǒng)應該是安全的，即使系統(tǒng)的所有東西都是公開的——除了一小部分信息——秘鑰。

這是公鑰密碼學的主要法則。

萊納斯定律（Linus's Law）

這是以 Linux 之父 Linus Torvalds 的名字命名的，該定律指出：

如果有足夠多的眼睛，所有的 bug 都將無所遁形。

可以使用著名的《大教堂與集市》來描述這個定律，它解釋了兩種不同的自由軟件開發(fā)模型之間的對比：

大教堂模型——每個軟件發(fā)行版都提供源代碼，但發(fā)行版之間的代碼開發(fā)僅限于一組專有的軟件開發(fā)人員。

集市模型——代碼開發(fā)通過互聯(lián)網(wǎng)公開進行。

結論？對源代碼進行更廣泛的公開測試、評審和實驗，就會更快地發(fā)現(xiàn)各種形式的 bug。

摩爾定律（Moore's Law）

單位成本的計算機算力每 24 個月翻一番。

最流行的版本是說：

集成電路上的晶體管數(shù)量大約每 18 個月會增加一倍。

或者：

計算機的處理速度每兩年翻一番！

 

沃斯定律（Wirth's Law）

軟件比硬件更容易變慢。

參考一下摩爾定律吧！

九九法則（Ninety-Ninety Rule）

前 90％的代碼占用了 10％的時間，其余的 10％代碼占用了剩下的 90％時間。

有人不同意這個的嗎？

克努特優(yōu)化法則（Knuth's Optimization Principle）

過早優(yōu)化是萬惡之源。

 

先寫代碼，然后找出瓶頸，最后才修復！

諾維格定律（Norvig's Law）

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

真香定律

別更新了，我學不動了！……真香。

所有程序員都逃不過的定律，同意嗎？

以上軟件開發(fā)定律，你都知道幾條？你還知道有哪些軟件開發(fā)的黃金定律嗎？歡迎留言告訴我們！

今日薦文

點擊下方圖片即可閱讀

中國互聯(lián)網(wǎng)公司開源項目調查報告