專注於Java領域優質技術，歡迎關注

翻譯自： 碼農翻身

和其他領域一樣，在軟件開發的世界中也有一些有趣而著名的定律，開發人員、管理人員還是架構師，都經常在會議或閒談中提到他們，很多時候我們都只是點頭附和，免得讓人知道自己其實根本沒聽說過布魯克斯(Brooks)、摩爾(Moore)或康威(Conway)這些大佬。

在這裏，我把這些定律整理出來，分享給大家。

墨菲定律 (Murphy's Law)

或許是所有的定律中最廣爲人知的，因爲它不僅僅適用於軟件開發領域。

凡是可能出錯的事就一定會出錯。

衍生定律：說髒話是唯一一門程序員用得都很流暢的語言。

推論：計算機會按照你寫出來的方式運行，而不是你臆想出來的。

防禦性編程、版本控制、測試驅動開發、模型驅動開發等等都是預防墨菲定律很好的做法。

布魯克斯法則(Brook's Law)

大多數開發人員都會經歷過布魯克斯定律：

向一個延期的項目增加人手只會讓它延期得更加厲害

如果一個項目進展落後了，僅僅增加人力很有可能會帶來災難性的後果。

相反，提高編程效率、審查軟件開發方法和技術架構是否合理，幾乎總是會比增加人力帶來更好的效果。如果沒有，這可能意味着霍夫施塔特定律在起作用。

霍夫斯塔特定律 (Hofstadter's Law)

霍夫斯塔特定律是由道格拉· 霍夫斯塔特(Douglas Hofstadter) 提出，並且以他的名字來命名的。

不要將這個定律與《生活大爆炸》中的倫納德·霍夫斯塔特混爲一談。即使他的話對你們一些人或許有用。

這個定律是這麼說的：

事情總是要花費比你預想更長的時間，即使你把霍夫斯塔特定律也考慮在內。

這條定律的遞歸性反映出，即使付出最大的努力，也知道任務是複雜的，去精確地估算它依然是非常難的，所以要給估算留一個緩衝區出來。

康威定律 (Conway's Law)

軟件的任何一部分都反應了創建它的組織結構

或者更清楚一點：

組織形式等同其設計的系統架構

許多組織都根據他們的技能來劃分團隊。因此會有前端開發、後端開發和數據庫開發組成的團隊。這會導致某人想要修改一個不屬於自己領域的東西會很難。

最好是按照有邊界的上下文(bounded context)來規劃團隊，並且越來越多的組織者也正在這麼做。像微服務這樣的架構圍繞服務邊界而不是孤立的技術體系劃分來組織他們的團隊。

康威定律帶來的具體的實踐建議就是：你想要什麼樣的系統設計，就架構什麼樣的團隊，這會帶來事半功倍的效果。

伯斯塔爾定律(Postel's Law)

又稱健壯性法則(Robustness principle)

發送時要保守，接收時要大方

Jon Postel 最初認爲正是這個原則讓TCP協議的實現很健壯。一些人認爲這正是 HTML 很成功的原因，也有一些人認爲這正是 HTML 很失敗的原因。（因爲HTML可以寫得不那麼嚴格，但是瀏覽器依然可以解析它）

帕累託法則 (Pareto Principle)

又稱80/20法則(The 80-20 rule)

對於許多現象來說，有 80% 的後果都是 20% 的原因造成的。

在軟件開發中的體現是： 代碼中80%的錯誤都是由代碼中的20%引起的。

另外，公司80%的工作是由20%的員工完成的。問題是你並不總是清楚誰是那20%。

彼得原則(The Peter Principle)

該原則還是比較打擊人的，特別是你碰巧正在經歷的話。

在等級制度中，每個員工都傾向於提升到他無法勝任的等級

在各種組織中，由於習慣於對在某個等級上稱職的人員進行晉升提拔，因而僱員總是趨向於被晉升到其不稱職的地位。

一旦組織中的相當部分人員被推到了其不稱職的級別，就會造成組織的人浮於事，效率低下，導致平庸者出人頭地，發展停滯。

柯克霍夫原則(Kerchkhoff's Principle)

在密碼學中，即使一個系統中的所有東西都是公開的（密鑰除外），該系統也應當是安全的。

這就是非對稱加密的主要原則。

林納斯定律 (Linus's Law)

以Linux之父林納斯·託瓦茲（Linus Torvalds）的名字命名，該定律表述爲：

衆目睽睽之下，一切 bug 都無所遁形

這個定律出自著名的文集《大教堂與集市》，這個文集對比了兩種不同的開源軟件開發模型。

• 大教堂模型，每個軟件發行版都伴有源代碼，但是僅限於軟件開發人員查看。
• 集市模型，以互聯網爲媒介，代碼開發的過程完全暴露在大衆的視野下。

被公開審查、測試的代碼越多，各種形式的錯誤就能更快地被發現。

摩爾定律 (Moore's Law)

每一美元所能買到的電腦性能，將每隔24個月翻一番。

最流行的版本是：

集成電路上可容納的元器件的數目，約每隔18個月便會增加一倍。

或

計算機的處理性能每隔兩年翻一倍。

90-90法則 (Ninety-ninety rule)

前90%的代碼要花費10%的開發時間，剩餘的10%的代碼要再花費90%的開發時間。

如此真實。還會有人不同意嗎？

克努特優化原則 (Knuth's optimization principle)

不成熟的優化是萬惡之源。

先把代碼寫出來，定位瓶頸所在，然後優化它。

諾維格定律 (Norvig's Law)

當公司的市場份額超過50%之後，就不能再翻番了。

在一個市場佔主導地位的公司必須不斷開拓新財源，才能長盛不衰。

寫在最後

這就是我喜歡的“定律”， 他們都有自己的故事和背景。作爲軟件開發人員你必須熟悉他們。

你也許會贊同或不贊同某條定律，或在其中任何一條有過有趣的經歷，歡迎在下方留言討論！