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

2 破窗定律

3 奧卡姆剃刀（簡約法則）

4 鄧寧-克魯格效應

5 彼得原理

6 帕金森定律

7 霍夫施塔特定律

8 康威定律

9 墨菲定律

10 布魯克定律

11 波斯特定律

12 克奇霍夫原理

13 萊納斯（Linus）定律

14 沃斯定律

15 克努斯的優化原則

16 保持懷疑

人們在圍繞軟件開發的討論中，幾乎不可避免會隨口引用一兩條原則。

你可能聽過人們說：“這行不通，因為‘X法則’！”。或者“你不知道‘Y原則’嗎？”你是哪種類型的軟件開發人員？

有許多規律和原則可以引用，其中大部分都基于真理。然而，盲目地使用像上面這樣的絕對陳述來應用它們肯定會導致自負和失敗。

本文列舉了一些可以應用于軟件開發的最流行的規律和原則。對于每條定律，我們將快速討論其主要內容，然后探討如何將其應用于軟件開發（也許何時不應該）。

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

內容

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

我們可以看到生活的許多領域遵守著這條規則，例如：

世界上最富有的 20% 的人創造了世界 80% 的收入。

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

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

如何應用在軟件開發中？

我們可以從帕累托法則中獲得的主要好處是專注。它可以幫助我們專注于重要的事情（20%），而不是在不重要的事情（其他 80%）上浪費時間和精力。不重要的事情對我們來說往往很重要，因為這樣的事情總是有太多（而且看起來很緊急） 。但是最好的結果往往是通過關注重要的少數來達成的。

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

專注于實現 80% 產品價值的那 20% 的產品功能。

專注于導致 80% 用戶使用異常的那 20% 的錯誤。

專注于實現 80% 的產品功能需要的那 20%總構建時間

……

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

順便說一下，敏捷和 DevOps 等現代開發方法有助于獲得這種關注！具有定期用戶反饋的快速迭代允許對重要事項進行數據驅動的決策。諸如基于主干的帶有功能標記的開發之類的實踐可以幫助軟件團隊實現這一目標。

2 破窗定律

內容

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

一般來說：混亂會招致更多的混亂。

如果我們的環境是原始的，我們就會有動力保持這種狀態。環境中的混亂越多，我們添加混亂的門檻就越低。畢竟已經混亂了……誰在乎我們是否再添加一點呢？

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

如何應用在軟件開發中？

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

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

3 奧卡姆剃刀（簡約法則）

內容

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

如何應用在軟件開發中？

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

下次用戶報告錯誤時，請維護事件調查文檔。寫下你對導致問題的原因的假設。然后，對于每個假設，列出事實和猜想。如果假設被證明是正確的，則將其標記為事實。如果一個假設被證明是錯誤的，請將其從文檔中刪除或將其標記為錯誤。在任何時候，你現在都可以將時間集中在最可能的假設上，而不是浪費時間轉移注意力。

4 鄧寧-克魯格效應

內容

鄧寧-克魯格效應表明，沒有經驗的人往往會高估自己的能力，而有經驗的人往往會低估自己的能力。

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

如何應用在軟件開發中？

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

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

不過，這只適用于安全的環境。在個人主義被美化的環境中，結對或群體編程會導致更多的自我懷疑或更多的優越感妄想。

5 彼得原理

內容

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

如何應用在軟件開發中？

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

6 帕金森定律

內容

帕金森定律指出，工作總是會填滿分配給它的時間。如果你的項目在兩周內有截止日期，則該項目將不會在此之前完成。可能需要更長的時間，是的，但絕不會少于我們為它分配的時間，因為我們正在用不必要的工作或拖延來填補時間。

如何應用在軟件開發中？

帕金森定律的主要驅動因素是：

拖延癥（“截止日期太遠了，所以我現在不需要匆忙……”）

范圍蔓延（“當然，我們可以添加這個小功能，它不會花費我們太多時間......”）

為了對抗拖延，我們可以在幾天而不是幾周或幾個月內設定最后期限。比如說在接下來的 2-3 天內需要做什么才能朝著目標前進？一個（健康的！）截止日期可以給我們足夠的動力，不要陷入拖延癥的低谷。為了防止范圍蔓延，我們應該非常清楚地了解我們試圖通過項目實現的目標。成功的衡量標準是什么？這個新功能是否會增加這些指標？那么如果每個人都明白這項工作需要更長的時間，我們應該添加它。如果新功能與使命宣言不匹配，請拋棄它。

7 霍夫施塔特定律

內容

霍夫施塔特定律指出“它總是比你預期的要長，即使你考慮到霍夫施塔特定律”。即使你了解了這條定律，并增加了項目的時間分配，它仍然會比你預期的要長。這與帕金森定律密切相關，即工作總是會填滿分配給它的時間。只是霍夫施塔特定律說它填充的時間超過了分配的時間。

這條定律得到了心理學的支持。我們容易犯所謂的“計劃謬誤”，即在估算工作量時，我們通常不會考慮所有可用信息，即使我們認為我們已經考慮了。我們的估計幾乎總是主觀的，很少是正確的。

如何應用在軟件開發中？

在軟件開發中（以及任何其他基于項目的工作，真的），我們人類的樂觀主義占了上風。估計幾乎總是過于樂觀。為了減少霍夫施塔特定律的影響，我們可以嘗試盡可能客觀地進行估計。寫下關于項目的假設和事實清單。將每個清單元素標記為假設或事實，以使數據質量可見并管理預期。不要依賴直覺，因為每個人的感受都不一樣。寫下估算值，讓你的大腦思考它們。將它們與其他人的估計進行比較，然后討論差異。

即便如此，它仍然只是一個估計，很可能不能反映現實。如果估算不是基于統計數據或其他歷史數據，那么它的價值就非常低，因此與要求你估算的人一起管理預期總是好的——這總是會出錯的。如果你讓它盡可能客觀，它就會減少錯誤。

8 康威定律

內容

康威定律指出，組織創建的任何系統都將類似于該組織的團隊和溝通結構。如果你有 10 個團隊在一個系統上工作，你很可能會得到 10 個相互通信的子系統。

如何應用在軟件開發中？

我們可以應用所謂的逆康威機動：創建最能支持我們想要構建的系統架構的組織結構。沒有固定的團隊結構，而是要有足夠的靈活性來創建和解散團隊，這對系統的當前狀態是最好的。

9 墨菲定律

內容

墨菲定律說，任何可能出錯的事情，都會出錯。它經常在意外發生后被引用。

如何應用在軟件開發中？

軟件開發是一個容易出錯的職業。出錯的主要來源是bug。沒有任何軟件不存在挑戰用戶耐心的錯誤或事件。我們可以通過在日常軟件開發實踐中養成減少錯誤影響的習慣來抵御墨菲定律。我們無法完全避免錯誤，但我們可以而且應該減少它們對用戶的影響。對抗墨菲定律最有用的做法是特征標記。

如果我們使用像 LaunchDarkly 這樣的功能標記平臺，我們可以在功能標記后面將更改部署到生產中。然后，我們可以使用有針對性的發布來激活內部 dogfooding 的標志，然后對少量友好的 Beta 用戶發布，最后將其發布給所有用戶。通過這種方式，我們可以從越來越關鍵的用戶群體那里獲得關于變化的反饋。如果更改出錯（并且在某些時候會出錯），影響很小，因為只有一小部分用戶組會受到它的影響。而且，該標志可以快速關閉。

10 布魯克定律

內容

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

如何應用在軟件開發中？

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

11 波斯特定律

內容

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

如何應用在軟件開發中？

該定律源于軟件開發，因此非常直接適用。你的軟件與其他軟件或開發人員之間的接口應允許不同形式的輸入以實現穩健性：

為了向后兼容，新版本的接口應該接受舊版本和新版本的數據

為了更好的用戶體驗，UI 中的表單應該接受不同格式的數據，這樣用戶就不必擔心格式。

但是，如果我們愿意接受不同格式的數據，我們在處理這些數據時就必須保守。我們必須審查無效值，并確保我們不會因為允許太多不同的格式而損害系統的安全性。SQL 注入是一種可能的攻擊，它是通過對用戶輸入過于寬松而造成的。

12 克奇霍夫原理

內容

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

如何應用在軟件開發中？

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

13 萊納斯（Linus）定律

內容

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

如何應用在軟件開發中？

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

這種做法也進入了閉源開發，但根據 Linus 定律，拉取請求在閉源環境（只有少數人查看它）中的作用不如在開源環境中（其中可能很多貢獻者都在看它）。其他為代碼添加更多眼睛的做法是結對編程和群體編程。至少在閉源環境中，這些在避免錯誤方面比拉取請求審查更有效，因為每個人都參與了代碼的初始階段，這為每個人提供了更好的上下文來理解代碼和潛在的錯誤。

14 沃斯定律

內容

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

如何應用在軟件開發中？

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

15 克努斯的優化原則

內容

Donald Knuth 在他的一部作品中寫了“過早優化是萬惡之源”這句話，這句話經常斷章取意，并被用作根本不關心優化代碼的借口。

如何應用在軟件開發中？

根據 Knuth 定律，我們不應該浪費精力過早地優化代碼。然而，根據沃斯定律，我們也不應該依賴硬件足夠快來執行優化不當的代碼。最后，這就是我從這些原則中得出的結論：優化可以輕松完成的代碼，無需太多努力：例如，編寫幾行額外代碼以避免經歷可能包含大量項目的循環。優化一直在執行的關鍵業務的代碼。除此之外，不要在優化代碼上花太多精力，除非你已經確定了一個性能瓶頸。

16 保持懷疑

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