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

翻譯| 碼農(nóng)翻身

和其他領(lǐng)域一樣，在軟件開發(fā)的世界中也有一些有趣而著名的定律，開發(fā)人員、管理人員還是架構(gòu)師，都經(jīng)常在會(huì)議或閑談中提到他們，很多時(shí)候我們都只是點(diǎn)頭附和，免得讓人知道自己其實(shí)根本沒(méi)聽說(shuō)過(guò)布魯克斯(Brooks)、摩爾(Moore)或康威(Conway)這些大佬。

在這里，我把這些定律整理出來(lái)，分享給大家。

墨菲定律 (Murphy's Law)

或許是所有的定律中最廣為人知的，因?yàn)樗粌H僅適用于軟件開發(fā)領(lǐng)域。

凡是可能出錯(cuò)的事就一定會(huì)出錯(cuò)。

衍生定律：說(shuō)臟話是唯一一門程序員用得都很流暢的語(yǔ)言。

推論：計(jì)算機(jī)會(huì)按照你寫出來(lái)的方式運(yùn)行，而不是你臆想出來(lái)的。

防御性編程、版本控制、測(cè)試驅(qū)動(dòng)開發(fā)、模型驅(qū)動(dòng)開發(fā)等等都是預(yù)防墨菲定律很好的做法。

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

大多數(shù)開發(fā)人員都會(huì)經(jīng)歷過(guò)布魯克斯定律：

向一個(gè)延期的項(xiàng)目增加人手只會(huì)讓它延期得更加厲害

如果一個(gè)項(xiàng)目進(jìn)展落后了，僅僅增加人力很有可能會(huì)帶來(lái)災(zāi)難性的后果。

相反，提高編程效率、審查軟件開發(fā)方法和技術(shù)架構(gòu)是否合理，幾乎總是會(huì)比增加人力帶來(lái)更好的效果。如果沒(méi)有，這可能意味著霍夫施塔特定律在起作用。

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

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

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

這個(gè)定律是這么說(shuō)的：

事情總是要花費(fèi)比你預(yù)想更長(zhǎng)的時(shí)間，即使你把霍夫斯塔特定律也考慮在內(nèi)。

這條定律的遞歸性反映出，即使付出最大的努力，也知道任務(wù)是復(fù)雜的，去精確地估算它依然是非常難的，所以要給估算留一個(gè)緩沖區(qū)出來(lái)。?

康威定律 (Conway's Law)

軟件的任何一部分都反應(yīng)了創(chuàng)建它的組織結(jié)構(gòu)

或者更清楚一點(diǎn)：

組織形式等同其設(shè)計(jì)的系統(tǒng)架構(gòu)

許多組織都根據(jù)他們的技能來(lái)劃分團(tuán)隊(duì)。因此會(huì)有前端開發(fā)、后端開發(fā)和數(shù)據(jù)庫(kù)開發(fā)組成的團(tuán)隊(duì)。這會(huì)導(dǎo)致某人想要修改一個(gè)不屬于自己領(lǐng)域的東西會(huì)很難。

最好是按照有邊界的上下文(bounded context)來(lái)規(guī)劃團(tuán)隊(duì)，并且越來(lái)越多的組織者也正在這么做。像微服務(wù)這樣的架構(gòu)圍繞服務(wù)邊界而不是孤立的技術(shù)體系劃分來(lái)組織他們的團(tuán)隊(duì)。

康威定律帶來(lái)的具體的實(shí)踐建議就是：你想要什么樣的系統(tǒng)設(shè)計(jì)，就架構(gòu)什么樣的團(tuán)隊(duì)，這會(huì)帶來(lái)事半功倍的效果。

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

又稱健壯性法則(Robustness principle)

發(fā)送時(shí)要保守，接收時(shí)要大方

Jon Postel 最初認(rèn)為正是這個(gè)原則讓TCP協(xié)議的實(shí)現(xiàn)很健壯。一些人認(rèn)為這正是 HTML 很成功的原因，也有一些人認(rèn)為這正是 HTML 很失敗的原因。（因?yàn)镠TML可以寫得不那么嚴(yán)格，但是瀏覽器依然可以解析它）

帕累托法則 (Pareto Principle)

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

對(duì)于許多現(xiàn)象來(lái)說(shuō)，有 80% 的后果都是 20% 的原因造成的。

在軟件開發(fā)中的體現(xiàn)是：?代碼中80%的錯(cuò)誤都是由代碼中的20%引起的。

另外，公司80%的工作是由20%的員工完成的。問(wèn)題是你并不總是清楚誰(shuí)是那20%。

彼得原則(The Peter Principle)

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

在等級(jí)制度中，每個(gè)員工都傾向于提升到他無(wú)法勝任的等級(jí)

在各種組織中，由于習(xí)慣于對(duì)在某個(gè)等級(jí)上稱職的人員進(jìn)行晉升提拔，因而雇員總是趨向于被晉升到其不稱職的地位。

一旦組織中的相當(dāng)部分人員被推到了其不稱職的級(jí)別，就會(huì)造成組織的人浮于事，效率低下，導(dǎo)致平庸者出人頭地，發(fā)展停滯。

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

在密碼學(xué)中，即使一個(gè)系統(tǒng)中的所有東西都是公開的（密鑰除外），該系統(tǒng)也應(yīng)當(dāng)是安全的。

這就是非對(duì)稱加密的主要原則。

林納斯定律 (Linus's Law)

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

眾目睽睽之下，一切 bug 都無(wú)所遁形

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

• 大教堂模型，每個(gè)軟件發(fā)行版都伴有源代碼，但是僅限于軟件開發(fā)人員查看。

• 集市模型，以互聯(lián)網(wǎng)為媒介，代碼開發(fā)的過(guò)程完全暴露在大眾的視野下。

被公開審查、測(cè)試的代碼越多，各種形式的錯(cuò)誤就能更快地被發(fā)現(xiàn)。

摩爾定律 (Moore's Law)

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

最流行的版本是：

集成電路上可容納的元器件的數(shù)目，約每隔18個(gè)月便會(huì)增加一倍。

或

計(jì)算機(jī)的處理性能每隔兩年翻一倍。

90-90法則 (Ninety-ninety rule)

前90%的代碼要花費(fèi)90%的開發(fā)時(shí)間，剩余的10%的代碼要再花費(fèi)90%的開發(fā)時(shí)間。

如此真實(shí)。還會(huì)有人不同意嗎？

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

不成熟的優(yōu)化是萬(wàn)惡之源。

先把代碼寫出來(lái)，定位瓶頸所在，然后優(yōu)化它。

諾維格定律 (Norvig's Law)

當(dāng)公司的市場(chǎng)份額超過(guò)50%之后，就不能再翻番了。

在一個(gè)市場(chǎng)占主導(dǎo)地位的公司必須不斷開拓新財(cái)源，才能長(zhǎng)盛不衰。

寫在最后

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

你也許會(huì)贊同或不贊同某條定律，或在其中任何一條有過(guò)有趣的經(jīng)歷，歡迎在下方留言討論！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。