1 帕累托法則（80/20 法則）

2 破窗定律

3 奧卡姆剃刀（簡(jiǎn)約法則）

4 鄧寧-克魯格效應(yīng)

5 彼得原理

6 帕金森定律

7 霍夫施塔特定律

8 康威定律

9 墨菲定律

10 布魯克定律

11 波斯特定律

12 克奇霍夫原理

13 萊納斯（Linus）定律

14 沃斯定律

15 克努斯的優(yōu)化原則

16 保持懷疑

人們?cè)趪@軟件開發(fā)的討論中，幾乎不可避免會(huì)隨口引用一兩條原則。

你可能聽過人們說：“這行不通，因?yàn)椤甔法則’！”?；蛘摺澳悴恢馈甕原則’嗎？”你是哪種類型的軟件開發(fā)人員？

有許多規(guī)律和原則可以引用，其中大部分都基于真理。然而，盲目地使用像上面這樣的絕對(duì)陳述來應(yīng)用它們肯定會(huì)導(dǎo)致自負(fù)和失敗。

本文列舉了一些可以應(yīng)用于軟件開發(fā)的最流行的規(guī)律和原則。對(duì)于每條定律，我們將快速討論其主要內(nèi)容，然后探討如何將其應(yīng)用于軟件開發(fā)（也許何時(shí)不應(yīng)該）。

1 帕累托法則（80/20 法則）

內(nèi)容

帕累托法則指出，通常 80% 的結(jié)果來自 20% 的原因。數(shù)字 80 和 20 無論如何都不是精確的，但該原則的總體思路是結(jié)果通常分布不均。

我們可以看到生活的許多領(lǐng)域遵守著這條規(guī)則，例如：

世界上最富有的 20% 的人創(chuàng)造了世界 80% 的收入。

80% 的犯罪是由 20%的罪犯所為（自 2020 年以來）。

我們知道 80% 的病毒傳播來自 20% 的受感染人群。

如何應(yīng)用在軟件開發(fā)中？

我們可以從帕累托法則中獲得的主要好處是專注。它可以幫助我們專注于重要的事情（20%），而不是在不重要的事情（其他 80%）上浪費(fèi)時(shí)間和精力。不重要的事情對(duì)我們來說往往很重要，因?yàn)檫@樣的事情總是有太多（而且看起來很緊急） 。但是最好的結(jié)果往往是通過關(guān)注重要的少數(shù)來達(dá)成的。

在軟件開發(fā)中，我們可以使用它來專注于構(gòu)建正確的功能，例如：

專注于實(shí)現(xiàn) 80% 產(chǎn)品價(jià)值的那 20% 的產(chǎn)品功能。

專注于導(dǎo)致 80% 用戶使用異常的那 20% 的錯(cuò)誤。

專注于實(shí)現(xiàn) 80% 的產(chǎn)品功能需要的那 20%總構(gòu)建時(shí)間

……

只要問“現(xiàn)在最重要的事情是什么？”就可以幫助建立下一個(gè)最重要的事情，而不是下一個(gè)最緊急的事情。

順便說一下，敏捷和 DevOps 等現(xiàn)代開發(fā)方法有助于獲得這種關(guān)注！具有定期用戶反饋的快速迭代允許對(duì)重要事項(xiàng)進(jìn)行數(shù)據(jù)驅(qū)動(dòng)的決策。諸如基于主干的帶有功能標(biāo)記的開發(fā)之類的實(shí)踐可以幫助軟件團(tuán)隊(duì)實(shí)現(xiàn)這一目標(biāo)。

2 破窗定律

內(nèi)容

破碎的窗戶會(huì)招致破壞，因此很快所有窗戶都被打破。

一般來說：混亂會(huì)招致更多的混亂。

如果我們的環(huán)境是原始的，我們就會(huì)有動(dòng)力保持這種狀態(tài)。環(huán)境中的混亂越多，我們添加混亂的門檻就越低。畢竟已經(jīng)混亂了……誰(shuí)在乎我們是否再添加一點(diǎn)呢？

我們可以從這條規(guī)則中獲得的主要好處是我們應(yīng)該意識(shí)到我們周圍的混亂。如果它已經(jīng)到了人們習(xí)慣于不再關(guān)心它的程度，那么最好為混亂帶來一些秩序。

如何應(yīng)用在軟件開發(fā)中？

在軟件開發(fā)中，我們可以將其應(yīng)用于代碼質(zhì)量：我們引入代碼庫(kù)的每一種代碼異味（Code Smell）都會(huì)降低我們添加更多代碼異味的門檻。我們應(yīng)該 [[Start Clean]] 并保持代碼庫(kù)干凈以避免這種情況發(fā)生。許多代碼庫(kù)如此難以理解和維護(hù)的原因是，破窗已經(jīng)悄然出現(xiàn)并且沒有足夠快地修復(fù)。

我們也可以將這個(gè)原則應(yīng)用到測(cè)試覆蓋率上：一旦有一定數(shù)量的代碼進(jìn)入了未被測(cè)試覆蓋的代碼庫(kù)，就會(huì)添加更多未被覆蓋的代碼。這是保持 100% 代碼覆蓋率（應(yīng)該覆蓋的代碼的）的論據(jù)，因此我們可以在窗口破裂之前看到裂縫。

3 奧卡姆剃刀（簡(jiǎn)約法則）

內(nèi)容

哲學(xué)剃刀是一種通過消除（或“削除”）不太可能的假設(shè)來幫助解釋某些事情的原則。奧卡姆剃刀表示，如果有多個(gè)假設(shè)，我們應(yīng)該選擇假設(shè)條件最少的假設(shè)（這很可能是解釋最簡(jiǎn)單的假設(shè)）。

如何應(yīng)用在軟件開發(fā)中？

我們可以在事件分析中應(yīng)用奧卡姆剃刀。你可能遇到過這樣的情況：用戶報(bào)告了你的應(yīng)用程序存在問題，但你不知道導(dǎo)致問題的原因。因此，你正在搜索日志和指標(biāo)，試圖找到根本原因。

下次用戶報(bào)告錯(cuò)誤時(shí)，請(qǐng)維護(hù)事件調(diào)查文檔。寫下你對(duì)導(dǎo)致問題的原因的假設(shè)。然后，對(duì)于每個(gè)假設(shè)，列出事實(shí)和猜想。如果假設(shè)被證明是正確的，則將其標(biāo)記為事實(shí)。如果一個(gè)假設(shè)被證明是錯(cuò)誤的，請(qǐng)將其從文檔中刪除或?qū)⑵錁?biāo)記為錯(cuò)誤。在任何時(shí)候，你現(xiàn)在都可以將時(shí)間集中在最可能的假設(shè)上，而不是浪費(fèi)時(shí)間轉(zhuǎn)移注意力。

4 鄧寧-克魯格效應(yīng)

內(nèi)容

鄧寧-克魯格效應(yīng)表明，沒有經(jīng)驗(yàn)的人往往會(huì)高估自己的能力，而有經(jīng)驗(yàn)的人往往會(huì)低估自己的能力。

你不擅長(zhǎng)某件事，但你會(huì)認(rèn)為你擅長(zhǎng)它。如果你擅長(zhǎng)某事，你認(rèn)為你不擅長(zhǎng) - 這可能導(dǎo)致冒名頂替綜合癥，這讓你懷疑自己的能力，以至于你在其他具有相似技能的人中感到不舒服 （害怕別人認(rèn)為你說的不正確）。

如何應(yīng)用在軟件開發(fā)中？

意識(shí)到這種認(rèn)知偏差已經(jīng)是朝著正確方向邁出的良好一步。它將幫助你更好地評(píng)估自己的技能，以便你可以尋求幫助，或者克服自我懷疑并自己行動(dòng)。

有助于消除鄧寧-克魯格效應(yīng)和冒名頂替綜合癥的一種做法是結(jié)對(duì)或群體編程。你不是獨(dú)自工作，沉浸在自我懷疑或優(yōu)越感中，而是與其他人密切合作，邊工作邊交流思想、學(xué)習(xí)和教學(xué)。

不過，這只適用于安全的環(huán)境。在個(gè)人主義被美化的環(huán)境中，結(jié)對(duì)或群體編程會(huì)導(dǎo)致更多的自我懷疑或更多的優(yōu)越感妄想。

5 彼得原理

內(nèi)容

彼得原理指出，只要你在工作中表現(xiàn)出色，你就會(huì)得到晉升，直到你晉升得到一份你不稱職的工作。由于你不再成功，你將不再獲得晉升，這意味著你將生活在一份不會(huì)給你帶來滿足感或成功的工作中，通常是在你的余生中。前景黯淡！

如何應(yīng)用在軟件開發(fā)中？

在軟件開發(fā)中，當(dāng)你將角色從開發(fā)人員職業(yè)轉(zhuǎn)換為管理職業(yè)時(shí)，彼得原則通常適用。然而，成為一名優(yōu)秀的開發(fā)人員并不一定意味著你是一名優(yōu)秀的經(jīng)理?；蛘?，你可能是一名優(yōu)秀的經(jīng)理，但不要在開發(fā)人員的工作上獲得經(jīng)理工作的滿足感，這意味著你沒有全力以赴（這就是我的情況）。在任何情況下，你都很悲慘，在你面前的職業(yè)道路上看不到任何未來的發(fā)展。在這種情況下，退后一步想想，你希望你的職業(yè)是什么樣子的。然后，轉(zhuǎn)換角色（或公司，如果需要）以獲得你想要的角色。

6 帕金森定律

內(nèi)容

帕金森定律指出，工作總是會(huì)填滿分配給它的時(shí)間。如果你的項(xiàng)目在兩周內(nèi)有截止日期，則該項(xiàng)目將不會(huì)在此之前完成?？赡苄枰L(zhǎng)的時(shí)間，是的，但絕不會(huì)少于我們?yōu)樗峙涞臅r(shí)間，因?yàn)槲覀冋谟貌槐匾墓ぷ骰蛲涎觼硖钛a(bǔ)時(shí)間。

如何應(yīng)用在軟件開發(fā)中？

帕金森定律的主要驅(qū)動(dòng)因素是：

拖延癥（“截止日期太遠(yuǎn)了，所以我現(xiàn)在不需要匆忙……”）

范圍蔓延（“當(dāng)然，我們可以添加這個(gè)小功能，它不會(huì)花費(fèi)我們太多時(shí)間......”）

為了對(duì)抗拖延，我們可以在幾天而不是幾周或幾個(gè)月內(nèi)設(shè)定最后期限。比如說在接下來的 2-3 天內(nèi)需要做什么才能朝著目標(biāo)前進(jìn)？一個(gè)（健康的?。┙刂谷掌诳梢越o我們足夠的動(dòng)力，不要陷入拖延癥的低谷。為了防止范圍蔓延，我們應(yīng)該非常清楚地了解我們?cè)噲D通過項(xiàng)目實(shí)現(xiàn)的目標(biāo)。成功的衡量標(biāo)準(zhǔn)是什么？這個(gè)新功能是否會(huì)增加這些指標(biāo)？那么如果每個(gè)人都明白這項(xiàng)工作需要更長(zhǎng)的時(shí)間，我們應(yīng)該添加它。如果新功能與使命宣言不匹配，請(qǐng)拋棄它。

7 霍夫施塔特定律

內(nèi)容

霍夫施塔特定律指出“它總是比你預(yù)期的要長(zhǎng)，即使你考慮到霍夫施塔特定律”。即使你了解了這條定律，并增加了項(xiàng)目的時(shí)間分配，它仍然會(huì)比你預(yù)期的要長(zhǎng)。這與帕金森定律密切相關(guān)，即工作總是會(huì)填滿分配給它的時(shí)間。只是霍夫施塔特定律說它填充的時(shí)間超過了分配的時(shí)間。

這條定律得到了心理學(xué)的支持。我們?nèi)菀追杆^的“計(jì)劃謬誤”，即在估算工作量時(shí)，我們通常不會(huì)考慮所有可用信息，即使我們認(rèn)為我們已經(jīng)考慮了。我們的估計(jì)幾乎總是主觀的，很少是正確的。

如何應(yīng)用在軟件開發(fā)中？

在軟件開發(fā)中（以及任何其他基于項(xiàng)目的工作，真的），我們?nèi)祟惖臉酚^主義占了上風(fēng)。估計(jì)幾乎總是過于樂觀。為了減少霍夫施塔特定律的影響，我們可以嘗試盡可能客觀地進(jìn)行估計(jì)。寫下關(guān)于項(xiàng)目的假設(shè)和事實(shí)清單。將每個(gè)清單元素標(biāo)記為假設(shè)或事實(shí)，以使數(shù)據(jù)質(zhì)量可見并管理預(yù)期。不要依賴直覺，因?yàn)槊總€(gè)人的感受都不一樣。寫下估算值，讓你的大腦思考它們。將它們與其他人的估計(jì)進(jìn)行比較，然后討論差異。

即便如此，它仍然只是一個(gè)估計(jì)，很可能不能反映現(xiàn)實(shí)。如果估算不是基于統(tǒng)計(jì)數(shù)據(jù)或其他歷史數(shù)據(jù)，那么它的價(jià)值就非常低，因此與要求你估算的人一起管理預(yù)期總是好的——這總是會(huì)出錯(cuò)的。如果你讓它盡可能客觀，它就會(huì)減少錯(cuò)誤。

8 康威定律

內(nèi)容

康威定律指出，組織創(chuàng)建的任何系統(tǒng)都將類似于該組織的團(tuán)隊(duì)和溝通結(jié)構(gòu)。如果你有 10 個(gè)團(tuán)隊(duì)在一個(gè)系統(tǒng)上工作，你很可能會(huì)得到 10 個(gè)相互通信的子系統(tǒng)。

如何應(yīng)用在軟件開發(fā)中？

我們可以應(yīng)用所謂的逆康威機(jī)動(dòng)：創(chuàng)建最能支持我們想要構(gòu)建的系統(tǒng)架構(gòu)的組織結(jié)構(gòu)。沒有固定的團(tuán)隊(duì)結(jié)構(gòu)，而是要有足夠的靈活性來創(chuàng)建和解散團(tuán)隊(duì)，這對(duì)系統(tǒng)的當(dāng)前狀態(tài)是最好的。

9 墨菲定律

內(nèi)容

墨菲定律說，任何可能出錯(cuò)的事情，都會(huì)出錯(cuò)。它經(jīng)常在意外發(fā)生后被引用。

如何應(yīng)用在軟件開發(fā)中？

軟件開發(fā)是一個(gè)容易出錯(cuò)的職業(yè)。出錯(cuò)的主要來源是bug。沒有任何軟件不存在挑戰(zhàn)用戶耐心的錯(cuò)誤或事件。我們可以通過在日常軟件開發(fā)實(shí)踐中養(yǎng)成減少錯(cuò)誤影響的習(xí)慣來抵御墨菲定律。我們無法完全避免錯(cuò)誤，但我們可以而且應(yīng)該減少它們對(duì)用戶的影響。對(duì)抗墨菲定律最有用的做法是特征標(biāo)記。

如果我們使用像 LaunchDarkly 這樣的功能標(biāo)記平臺(tái)，我們可以在功能標(biāo)記后面將更改部署到生產(chǎn)中。然后，我們可以使用有針對(duì)性的發(fā)布來激活內(nèi)部 dogfooding 的標(biāo)志，然后對(duì)少量友好的 Beta 用戶發(fā)布，最后將其發(fā)布給所有用戶。通過這種方式，我們可以從越來越關(guān)鍵的用戶群體那里獲得關(guān)于變化的反饋。如果更改出錯(cuò)（并且在某些時(shí)候會(huì)出錯(cuò)），影響很小，因?yàn)橹挥幸恍〔糠钟脩艚M會(huì)受到它的影響。而且，該標(biāo)志可以快速關(guān)閉。

10 布魯克定律

內(nèi)容

在經(jīng)典著作“人月神話”中，弗雷德·布魯克（Fred Brook）有句名言：為遲到的項(xiàng)目增加人力會(huì)使項(xiàng)目更晚。盡管本書討論的是軟件項(xiàng)目，但它適用于大多數(shù)類型的項(xiàng)目，甚至是軟件開發(fā)之外的項(xiàng)目。添加人員不會(huì)提高項(xiàng)目速度的原因是項(xiàng)目的通信開銷隨著添加到項(xiàng)目中的每個(gè)人呈指數(shù)增長(zhǎng)。2個(gè)人有1條通信路徑，5個(gè)人已經(jīng)有120條可能的通信路徑。新人安頓下來并確定他們需要的溝通路徑需要時(shí)間，這就是為什么在項(xiàng)目中添加新人時(shí)，遲到的項(xiàng)目會(huì)更晚。

如何應(yīng)用在軟件開發(fā)中？

很簡(jiǎn)單。更改截止日期，而不是將人員添加到已經(jīng)遲到的項(xiàng)目中。對(duì)在軟件項(xiàng)目中增加新人的期望要切合實(shí)際。將人員添加到項(xiàng)目中可能會(huì)在某個(gè)時(shí)候提高速度，但并非總是如此，當(dāng)然也不是立即。人員和團(tuán)隊(duì)需要時(shí)間來適應(yīng)日常工作，而在某些時(shí)候，工作無法充分并行化，因此增加更多人是沒有意義的。仔細(xì)考慮一個(gè)新人應(yīng)該完成什么任務(wù)，以及在將該人添加到項(xiàng)目中時(shí)你期望什么。

11 波斯特定律

內(nèi)容

Postel 定律也被稱為穩(wěn)健性原則，它指出你應(yīng)該“在你所做的事情上保守，在你接受別人的事情上開放”。換句話說，你可以接受多種不同形式的數(shù)據(jù)，以使你的軟件盡可能靈活，但你在處理這些數(shù)據(jù)時(shí)應(yīng)該非常小心，以免因無效或惡意數(shù)據(jù)而危及你的軟件。

如何應(yīng)用在軟件開發(fā)中？

該定律源于軟件開發(fā)，因此非常直接適用。你的軟件與其他軟件或開發(fā)人員之間的接口應(yīng)允許不同形式的輸入以實(shí)現(xiàn)穩(wěn)健性：

為了向后兼容，新版本的接口應(yīng)該接受舊版本和新版本的數(shù)據(jù)

為了更好的用戶體驗(yàn)，UI 中的表單應(yīng)該接受不同格式的數(shù)據(jù)，這樣用戶就不必?fù)?dān)心格式。

但是，如果我們?cè)敢饨邮懿煌袷降臄?shù)據(jù)，我們?cè)谔幚磉@些數(shù)據(jù)時(shí)就必須保守。我們必須審查無效值，并確保我們不會(huì)因?yàn)樵试S太多不同的格式而損害系統(tǒng)的安全性。SQL 注入是一種可能的攻擊，它是通過對(duì)用戶輸入過于寬松而造成的。

12 克奇霍夫原理

內(nèi)容

Kerchkhoff 的原則指出，加密系統(tǒng)應(yīng)該是安全的，即使它的加密方法是公開的。只有你用來解密某些東西的密鑰才需要是私有的。

如何應(yīng)用在軟件開發(fā)中？

這很簡(jiǎn)單，真的。永遠(yuǎn)不要相信要求其加密方法是私密的加密系統(tǒng)。這被稱為“默默無聞的安全”。像這樣的系統(tǒng)本質(zhì)上是不安全的。一旦該加密方法向公眾公開，它就容易受到攻擊。

13 萊納斯（Linus）定律

內(nèi)容

在關(guān)于 Linux 內(nèi)核開發(fā)的《大教堂與集市》一書中，埃里克·雷蒙德（Eric Raymond）寫道：“有足夠多的眼睛，就可讓所有問題浮現(xiàn)”。他將此稱為“萊納斯定律”以紀(jì)念萊納斯·托瓦茲。這意味著如果很多人看代碼比很少人看代碼可以更容易地暴露代碼中的錯(cuò)誤。

如何應(yīng)用在軟件開發(fā)中？

如果你想擺脫錯(cuò)誤，請(qǐng)讓其他人查看你的代碼。源于開源社區(qū)的一種常見做法是讓開發(fā)人員提出包含代碼更改的拉取請(qǐng)求，然后讓其他開發(fā)人員在將拉取請(qǐng)求合并到主分支之前審查該拉取請(qǐng)求。

這種做法也進(jìn)入了閉源開發(fā)，但根據(jù) Linus 定律，拉取請(qǐng)求在閉源環(huán)境（只有少數(shù)人查看它）中的作用不如在開源環(huán)境中（其中可能很多貢獻(xiàn)者都在看它）。其他為代碼添加更多眼睛的做法是結(jié)對(duì)編程和群體編程。至少在閉源環(huán)境中，這些在避免錯(cuò)誤方面比拉取請(qǐng)求審查更有效，因?yàn)槊總€(gè)人都參與了代碼的初始階段，這為每個(gè)人提供了更好的上下文來理解代碼和潛在的錯(cuò)誤。

14 沃斯定律

內(nèi)容

沃斯定律指出，軟件變慢的速度比硬件變快的速度要快。

如何應(yīng)用在軟件開發(fā)中？

不要依賴強(qiáng)大的硬件來運(yùn)行性能不佳的代碼。相反，編寫經(jīng)過優(yōu)化以表現(xiàn)良好的代碼。這必須與 （軟件開發(fā)定律：克努斯的優(yōu)化原則） 的格言相平衡，該格言說“過早的優(yōu)化是萬(wàn)惡之源”。與為用戶構(gòu)建新功能所花費(fèi)的精力相比，不要在使代碼運(yùn)行得更快上花費(fèi)更多的精力。通常，這是一種平衡行為。

15 克努斯的優(yōu)化原則

內(nèi)容

Donald Knuth 在他的一部作品中寫了“過早優(yōu)化是萬(wàn)惡之源”這句話，這句話經(jīng)常斷章取意，并被用作根本不關(guān)心優(yōu)化代碼的借口。

如何應(yīng)用在軟件開發(fā)中？

根據(jù) Knuth 定律，我們不應(yīng)該浪費(fèi)精力過早地優(yōu)化代碼。然而，根據(jù)沃斯定律，我們也不應(yīng)該依賴硬件足夠快來執(zhí)行優(yōu)化不當(dāng)?shù)拇a。最后，這就是我從這些原則中得出的結(jié)論：優(yōu)化可以輕松完成的代碼，無需太多努力：例如，編寫幾行額外代碼以避免經(jīng)歷可能包含大量項(xiàng)目的循環(huán)。優(yōu)化一直在執(zhí)行的關(guān)鍵業(yè)務(wù)的代碼。除此之外，不要在優(yōu)化代碼上花太多精力，除非你已經(jīng)確定了一個(gè)性能瓶頸。

16 保持懷疑

定律和原則是好的。這使我們能夠從某個(gè)角度評(píng)估某些情況，如果沒有它們，我們不可能了解這些情況的背后道理。然而，盲目地將定律和原則應(yīng)用于每種情況是行不通的。每一種情況都會(huì)存在微妙的變化，這可能意味著某個(gè)原則不能或不應(yīng)該適用。對(duì)你遇到的原則和定律保持懷疑。世界不是非黑即白的。