文|?https://www.timsommer.be/famous-laws-of-software-development/

翻譯| 碼農翻身

和其他領域一樣，在軟件開發的世界中也有一些有趣而著名的定律，開發人員、管理人員還是架構師，都經常在會議或閑談中提到他們，很多時候我們都只是點頭附和，免得讓人知道自己其實根本沒聽說過布魯克斯(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%的代碼要花費90%的開發時間，剩余的10%的代碼要再花費90%的開發時間。

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

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

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

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

諾維格定律 (Norvig's Law)

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

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

寫在最后

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

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

總結

以上是生活随笔為你收集整理的统治软件开发中的著名定律的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。