作者 | Tim Sommer

譯者 | 薛命燈

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

與其他領(lǐng)域一樣，軟件開發(fā)領(lǐng)域也有一些非常有趣的定律。程序員、技術(shù)經(jīng)理和架構(gòu)師們經(jīng)常在會(huì)議和聊天中提到它們。作為小白，我們常常只有點(diǎn)頭附和的份，因?yàn)槲覀儾幌Ｍ寣?duì)方知道我們實(shí)際上根本不知道布魯克、摩爾或者維斯都是什么人。

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

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

墨菲定律（Murphy's Law）

可能是最著名的定律之一，主要是因?yàn)樗粌H適用于軟件開發(fā)。

如果事情可能出錯(cuò)，它就會(huì)出錯(cuò)。

防御性編程、版本控制、末日?qǐng)鼍埃ㄡ槍?duì)那些該死的僵尸服務(wù)器攻擊）、TDD、MDD，等等，這些都是針對(duì)這一定律的防御性實(shí)踐。

布魯克定律（Brook's Law）

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

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

如果一個(gè)項(xiàng)目出現(xiàn)了延期，只是簡(jiǎn)單地增加人手很可能會(huì)帶來(lái)災(zāi)難性的后果。對(duì)編程效率、軟件開發(fā)方法、技術(shù)架構(gòu)等因素進(jìn)行評(píng)審總是會(huì)帶來(lái)更好的結(jié)果。如果沒(méi)有，那說(shuō)明霍夫施塔特定律也在起作用。

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

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

當(dāng)然，不要將這個(gè)定律與電視劇《大爆炸》里的 Leonard 混淆起來(lái)了，盡管他說(shuō)的一些話對(duì)某些人來(lái)說(shuō)是有一點(diǎn)意義的。

這個(gè)定律指出：

即使你考慮到了霍夫施塔特定律，項(xiàng)目的實(shí)際完成時(shí)間總是比預(yù)期的要長(zhǎng)。

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

這就是為什么在進(jìn)行項(xiàng)目預(yù)估時(shí)必須要有一個(gè)緩沖區(qū)。

康威定律（Conway’s Law）

軟件的結(jié)構(gòu)反映了開發(fā)軟件的組織的結(jié)構(gòu)。

或者說(shuō)得更清楚一點(diǎn)：

組織所設(shè)計(jì)的系統(tǒng)的結(jié)構(gòu)受限于組織的通信結(jié)構(gòu)。

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

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

因此，根據(jù)目標(biāo)軟件架構(gòu)來(lái)組建團(tuán)隊(duì)可以更容易實(shí)現(xiàn)軟件架構(gòu)，而這就是對(duì)抗康威法律的一種有效方式。

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

保守輸出，自由輸入。

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

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

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

80％的 bug 來(lái)自 20％的代碼，這個(gè)說(shuō)的就是帕累托法則。

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

彼得法則（The Peter ）

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

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

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

基爾霍夫法則（'s ）

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

這是公鑰密碼學(xué)的主要法則。

萊納斯定律（Linus's Law）

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

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

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

結(jié)論？對(duì)源代碼進(jìn)行更廣泛的公開測(cè)試、評(píng)審和實(shí)驗(yàn)，就會(huì)更快地發(fā)現(xiàn)各種形式的 bug。

摩爾定律（Moore's Law）

單位成本的計(jì)算機(jī)算力每 24 個(gè)月翻一番。

最流行的版本是說(shuō)：

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

或者：

計(jì)算機(jī)的處理速度每?jī)赡攴环?/p>

沃斯定律（Wirth's Law）

軟件比硬件更容易變慢。

參考一下摩爾定律吧！

九九法則（Ninety-Ninety Rule）

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

有人不同意這個(gè)的嗎？

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

過(guò)早優(yōu)化是萬(wàn)惡之源。

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

諾維格定律（Norvig's Law）

任何超過(guò) 50％滲透率的技術(shù)都不會(huì)再次翻倍（無(wú)論在多少個(gè)月內(nèi)）。

真香定律

別更新了，我學(xué)不動(dòng)了！……真香。

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

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

今日薦文

點(diǎn)擊下方圖片即可閱讀

中國(guó)互聯(lián)網(wǎng)公司開源項(xiàng)目調(diào)查報(bào)告

點(diǎn)個(gè)在看少個(gè) bug