與其他領(lǐng)域一樣，軟件開發(fā)中也有一些非常有趣的法則。 程序員，技術(shù)經(jīng)理和架構(gòu)師經(jīng)常在會(huì)議和聊天中提及他們。 作為小白，我們通常只是點(diǎn)頭同意，因?yàn)槲覀儾幌胱寣?duì)方知道我們實(shí)際上不知道布魯克，摩爾或魏斯是誰。 今天，我們將聆聽您必須承認(rèn)的那些軟件開發(fā)法律。

這些法律包括一些偉大的軟件開發(fā)神的法律或著名諺語(yǔ)。 它們都很有趣，值得一看，每部法律背后都有驚人的背景故事。

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

墨菲定律

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

如果出了什么問題，那就會(huì)出錯(cuò)。

第一個(gè)推論：您可能尚未編寫有效的代碼。

第二個(gè)推論：詛咒是所有程序員都能說流利的唯一語(yǔ)言。

結(jié)論：計(jì)算機(jī)將執(zhí)行您編寫的內(nèi)容（代碼），而不是您想要執(zhí)行的操作。

防御性編程，版本控制，世界末日情況（針對(duì)那些該死的僵尸服務(wù)器攻擊），TDD，MDD等，這些都是針對(duì)此法律的防御性做法。

布魯克定律

大多數(shù)開發(fā)人員自覺或不自覺地體驗(yàn)了布魯克定律。 法律規(guī)定：

是已被推遲的軟件項(xiàng)目。增加人力只會(huì)嚴(yán)重拖延該項(xiàng)目。

如果一個(gè)項(xiàng)目被延遲，僅僅增加人力可能會(huì)帶來災(zāi)難性的后果。 回顧諸如編程效率，軟件開發(fā)方法和技術(shù)體系結(jié)構(gòu)等因素將始終帶來更好的結(jié)果。 如果不是的，這意味著霍夫施塔特定律也在起作用。

霍夫施塔特定律

霍夫施塔特定律是道格拉斯·霍夫施塔特提出的，并以他的名字命名。

當(dāng)然，即使他說的某些話對(duì)某些人來說有一定意義，也請(qǐng)不要在電視連續(xù)劇《大爆炸》中將此法與倫納德·霍夫施塔特混淆。

of的定律指出：

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

此“定律”是關(guān)于準(zhǔn)確估計(jì)完成復(fù)雜任務(wù)所需的時(shí)間的難度。 該定律是遞歸的，反映了估算復(fù)雜項(xiàng)目的難度，即使您可能已盡了最大努力并且知道任務(wù)的復(fù)雜性。

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

康韋定律

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

或者更明確地說：

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

許多組織根據(jù)職能技能劃分團(tuán)隊(duì)，因此將有前端開發(fā)團(tuán)隊(duì)，后端開發(fā)團(tuán)隊(duì)和數(shù)據(jù)庫(kù)開發(fā)團(tuán)隊(duì)。 簡(jiǎn)而言之，如果某人想要更改的東西屬于其他人，那么他很難更改這些東西。

現(xiàn)在，越來越多的組織基于有限的上下文來組織團(tuán)隊(duì)，而微服務(wù)之類的體系結(jié)構(gòu)也正在基于服務(wù)邊界而不是孤立的技術(shù)體系結(jié)構(gòu)分區(qū)來構(gòu)建團(tuán)隊(duì)。

因此，通過根據(jù)目標(biāo)軟件體系結(jié)構(gòu)組成團(tuán)隊(duì)，可以更輕松地實(shí)現(xiàn)軟件體系結(jié)構(gòu)，這是抵制Conway法則的有效方法。

Postel定律或穩(wěn)健性定律

保守輸出，自由輸入。

Jon Postel最初將其用作實(shí)現(xiàn)健壯TCP的原理。 HTML中也反映了這一原理。 HTML的成功或失敗可以歸因于其許多屬性，但是對(duì)于HTML是成功還是失敗，不同的人有不同的看法。

帕累托原理或80/20規(guī)則

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

80％的錯(cuò)誤來自20％的代碼。 這是帕累托定律。

有人說，公司80％的工作是由20％的員工完成的。 問題是您不知道哪20％的員工是。

彼得原理

這是一個(gè)相當(dāng)令人沮喪的定律，尤其是如果您碰巧自己經(jīng)歷的定律。

在分層系統(tǒng)中，每個(gè)員工都傾向于被提升到他無法擔(dān)任的職位。

迪爾伯特（Dilbert）系列漫畫中有一些例子。

Kerchkhoff原理

在密碼術(shù)中，即使系統(tǒng)中的所有內(nèi)容都是公共的，系統(tǒng)也應(yīng)該是安全的，除了一小部分信息（密鑰）。

這是公鑰加密的主要法則。

Linus定律

這是以Linux之父Linus Torvalds的名字命名的。 法律規(guī)定：

如果眼中有足夠的蟲子，則所有蟲子都是不可見的。

著名的“大教堂和集市”可以用來描述該定律，它解釋了兩種不同的自由軟件開發(fā)模型之間的對(duì)比：

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

集市模型代碼開發(fā)是通過Internet公開完成的。

結(jié)論？ 對(duì)源代碼進(jìn)行更廣泛的公共測(cè)試，審查和試驗(yàn)將導(dǎo)致更快地發(fā)現(xiàn)各種形式的錯(cuò)誤。

摩爾定律

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

The的最流行版本是：

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

或：

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

Wirth定律

軟件比率硬件更有可能 慢下來。

請(qǐng)參閱摩爾定律！

九十法則

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

有人反對(duì)嗎？

Knuth的優(yōu)化原理

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

首先編寫代碼，然后找到瓶頸，最后加以解決！

諾維定律

任何滲透率超過50％的技術(shù)都將 再也不會(huì)再翻一番（無論有多少個(gè)月）。

真正的香精法則

不要更新它，我無法學(xué)習(xí)！...真正的香精。

是所有程序員都無法逃避的法律，是同意嗎？

您知道多少上述軟件開發(fā)法律？