軟件開發(fā)中的常見的15個定律和原則釋義及應用
軟件開發(fā)中的常見的15個定律和原則釋義及應用
原創(chuàng)2021-12-27 14:07·信碼由韁
在圍繞軟件開發(fā)的討論中，幾乎不可能避免引用一兩條定律。
“這行不通，因為‘X法則’！” 你可能聽過人們說?；蛘摺澳悴恢馈甕原則’嗎？ 你是哪種軟件開發(fā)人員？”。
有許多法律和原則可以引用，其中大部分都基于真理。然而，盲目地使用像上面這樣的絕對陳述來應用它們肯定會導致自負和失敗。
本文列舉了一些可以應用于軟件開發(fā)的最流行的規(guī)律和原則。對于每條規(guī)律，我們將快速討論其主要命題，然后探討如何將其應用于軟件開發(fā)（也許何時不應該）。
帕累托原則（80/20 規(guī)則）
解釋
帕累托原則指出，通常?80% 的結果來自 20% 的原因。數(shù)字 80 和 20 無論如何都不是精確的，但該原理的總體思路是結果通常分布不均。
我們可以在生活的許多領域遵守這條規(guī)則，例如：
世界上最富有的 20% 的人創(chuàng)造了世界上 80% 的收入，
80%的犯罪是由20%的罪犯所為
自 2020 年以來，我們知道 80% 的病毒傳播來自 20% 的受感染人群。
在軟件開發(fā)中的應用
我們可以從帕累托原則中獲得的主要好處是專注。它可以幫助我們專注于重要的事情（20%），而不是在不重要的事情（其他 80%）上浪費時間和精力。不重要的事情對我們來說似乎很重要，因為有太多（而且看起來很緊急）。但最好的結果往往是通過專注于重要的少數(shù)來實現(xiàn)的。
在軟件開發(fā)中，我們可以基于這個原則來專注于構建正確的功能，例如：
專注于構成產(chǎn)品價值 80% 的 20% 的產(chǎn)品功能，
專注于導致 80% 用戶沮喪的 20% 錯誤，
專注于 80% 的產(chǎn)品功能需要 20% 的總時間來構建，
......
只是問“現(xiàn)在最重要的事情是什么？” 能夠幫助你完成下一個最重要的事情，而不是下一個最緊急的事情。
順便說一下，敏捷和 DevOps 等現(xiàn)代開發(fā)方法有助于獲得這種關注！具有定期用戶反饋的快速迭代允許對重要事項進行數(shù)據(jù)驅動的決策。諸如基于主干的帶有功能標記的開發(fā)（例如使用?LaunchDarkly）之類的實踐可以幫助軟件團隊實現(xiàn)目標。
破窗定理
解釋
一扇被打破的窗戶會招來惡意破壞，所以用不了多久，所有的窗戶都被打破了。
一般來說：混亂會帶來更多的混亂。
如果我們的環(huán)境是原始的，我們就會有動力保持這種狀態(tài)。環(huán)境中的混亂越多，我們添加混亂的門檻就越低。畢竟已經(jīng)混亂了……誰在乎我們是否再添加一點呢？
我們可以從這條規(guī)則中獲得的主要好處是我們應該意識到我們周圍的混亂。如果人們習慣于它，不再關心它了，那么最好為混亂帶來一些秩序。
在軟件開發(fā)中的應用
在軟件開發(fā)中，我們可以將其應用于代碼質量：我們引入代碼庫的每一種代碼異味都會降低我們添加更多代碼異味的門檻。我們應該 [[開始清理]] 并保持代碼庫干凈以避免這種情況發(fā)生。許多代碼庫如此難以理解和維護的原因是，破窗已經(jīng)悄然出現(xiàn)并且沒有足夠快地修復。
我們也可以將這個原則應用到測試覆蓋率上：一旦有一定數(shù)量的代碼進入了未被測試覆蓋的代碼庫，就會添加更多未被覆蓋的代碼。這是保持 100% 代碼覆蓋率（應該覆蓋的代碼的）的論據(jù)，因此我們可以在窗口破裂之前看到裂縫。
奧卡姆剃刀
解釋
剃刀哲學是一種原理，它通過消除（或“削除”）不可能的解釋來幫助解釋某些事情。
奧卡姆剃刀指出，如果有多個假設，我們應該選擇假設最少的假設（這很可能是解釋最簡單的假設）。
在軟件開發(fā)中的應用
我們可以在事件分析中應用奧卡姆剃刀。您可能遇到過這樣的情況：用戶報告了您的應用程序存在問題，但您不知道導致問題的原因。因此，您搜索日志和指標，試圖找到根本原因。
下次用戶報告錯誤時，維護一個事件調查文檔。寫下您對導致問題的原因的假設。然后，對于每個假設，列出事實和假設。如果一個假設被證明是正確的，則將其標記為事實。如果某個假設被證明是錯誤的，請將其從文檔中刪除或將其標記為錯誤。在任何時候，您都可以將時間集中在最可能的假設上，而不是浪費時間尋找不相干的東西。
達克效應
解釋
鄧寧-克魯格效應表明，沒有經(jīng)驗的人往往會高估自己的能力，而有經(jīng)驗的人往往會低估自己的能力。
如果你不擅長某件事，你會認為你擅長它。如果你擅長某事，你認為你不擅長 - 這可能導致騙子綜合癥，這讓你非常懷疑自己的能力，以至于你在其他具有相似技能的人中感到不舒服 - 不必要地害怕被質疑是一個騙子。
在軟件開發(fā)中的應用
意識到這種認知偏差已經(jīng)是朝著正確方向邁出的重要一步。它將幫助您更好地評估自己的技能，以便您可以尋求幫助，或克服自我懷疑并自己動手。
有助于消除達克效應和騙子綜合癥的一種做法是結對或群體編程。你不是獨自工作，沉浸在自我懷疑或優(yōu)越感中，而是與其他人密切合作，邊工作邊交流思想、學習和教學。
不過，這只適用于安全的環(huán)境。在個人主義被美化的環(huán)境中，結對或群體編程會導致更多的自我懷疑或更多的優(yōu)越感妄想。
彼得原則
解釋
彼得原則指出，只要你成功，你就會得到晉升，直到你最終得到一份你不勝任的工作。由于您不再成功，您將不再獲得晉升，這意味著您將生活在一份不會給您帶來滿足感或成功的工作中，通常這種感覺將在一直伴隨在您的余生。
前景黯淡。
在軟件開發(fā)中的應用
在軟件開發(fā)中，當您將角色從開發(fā)人員職業(yè)轉換為管理職業(yè)時，彼得原則通常適用。然而，成為一名優(yōu)秀的開發(fā)人員并不一定意味著你是一名優(yōu)秀的經(jīng)理?；蛘?，您可能是一名優(yōu)秀的經(jīng)理，但卻不能從經(jīng)理工作中獲得開發(fā)工作中所能獲得的滿足感，這意味著您沒有全力以赴（這就是我的情況）。在任何情況下，你都很悲慘，在你面前的職業(yè)道路上看不到任何未來的發(fā)展。
在這種情況下，退后一步，決定你想要什么樣的職業(yè)生涯。然后，轉換角色（或公司，如果需要）以獲得您想要的角色。
帕金森定律
解釋
帕金森定律指出，工作總是會占據(jù)分配給它的時間。如果您的項目在兩周的截止日期，則該項目將不會在此之前完成。 可能需要更長的時間，是的，但絕不會少于我們?yōu)樗峙涞臅r間，因為我們正在用不必要的工作或拖延來填補時間。
在軟件開發(fā)中的應用
帕金森定律的主要驅動因素是：
拖延癥（“截止日期太遠了，所以我現(xiàn)在不需要趕時間……”），還有
范圍蔓延（“當然，我們可以添加這個小功能，它不會花費我們太多時間......”）。
為了戰(zhàn)勝拖延癥，我們可以把最后期限設置為幾天而不是幾周或內個月。在接下來的 2-3 天內需要做什么才能朝著目標前進？一個（健康的?。┙刂谷掌诳梢越o我們足夠的動力，讓我們不要陷入拖延癥的泥潭。
為了防止范圍蔓延，我們應該非常清楚地知道我們想要通過項目實現(xiàn)什么。成功的衡量標準是什么？ 這個新功能是否會增強這些指標？那么如果每個人都明白這項工作需要更長的時間，我們應該添加它。如果新功能不符合使命，那就不用管它。
霍夫施塔特定律
解釋
霍夫施塔特定律指出：“即使考慮了霍夫施塔特定律，它所花的時間也比你預期的長”。
即使您了解了這條法律，并增加了項目的時間分配，它仍然會比您預期的要長。這與帕金森定律密切相關，即工作總是會填滿分配給它的時間。只是霍夫施塔特定律說它填充的時間超過了分配的時間。
這條定律得到了心理學的支持。我們容易犯所謂的“計劃謬誤”，即在估算工作量時，我們通常不會考慮所有可用信息，即使我們認為我們已經(jīng)考慮了。我們的估計幾乎總是主觀的，很少是正確的。
在軟件開發(fā)中的應用
在軟件開發(fā)（以及任何其他基于項目的工作）中，我們人類的樂觀情緒發(fā)揮了很大作用。評估幾乎總是過于樂觀。
為了減少霍夫施塔特定律的影響，我們可以嘗試盡可能客觀地進行估計。
寫下關于項目的假設和事實。將每個項目標記為假設或事實，以使數(shù)據(jù)質量可見并管理預期。
不要依賴直覺，因為每個人的感受都不一樣。寫下估算值，讓你的大腦思考它們。將它們與其他人的估計進行比較，然后討論差異。
即便如此，它仍然只是一個估計，很可能不能反映現(xiàn)實。如果估算不是基于統(tǒng)計數(shù)據(jù)或其他歷史數(shù)據(jù)，那么它的價值就非常低，因此與要求您估算的人一起管理預期總是好的——這總是會出錯的。如果你讓它盡可能客觀，它就會減少錯誤。
康威定律
解釋
康威定律指出，一個組織創(chuàng)建的任何系統(tǒng)都與該組織的團隊和溝通結構相似。系統(tǒng)將在構建系統(tǒng)的團隊有接口的地方具備接口。如果你有 10 個團隊在一個系統(tǒng)上工作，你很可能會得到 10 個相互通信的子系統(tǒng)。
在軟件開發(fā)中的應用
我們可以應用所謂的逆康威策略：創(chuàng)建最能支持我們想要構建的系統(tǒng)架構的組織結構。
沒有固定的團隊結構，而是要有足夠的靈活性來創(chuàng)建和解散團隊，這對系統(tǒng)的當前狀態(tài)是最好的。
墨菲定律
解釋
墨菲定律說，任何可能出錯的事情，都會出錯。它經(jīng)常在意外發(fā)生后被引用。
在軟件開發(fā)中的應用
軟件開發(fā)是一個容易出錯的職業(yè)。出錯的主要來源是錯誤。沒有任何一款軟件不存在漏洞或事故，從而考驗測試用戶的耐心。
我們可以通過在日常軟件開發(fā)實踐中養(yǎng)成減少錯誤影響的習慣來抵御墨菲定律。我們無法完全避免錯誤，但我們可以而且應該減少它們對用戶的影響。
對抗墨菲定律最有用的做法是特征標記。如果我們使用像?LaunchDarkly?這樣的功能標記平臺，我們可以在功能標記后面將更改部署到生產(chǎn)中。然后，我們可以使用有針對性的推出來激活內部 dogfooding 的標志，然后為少量友好的 Beta 用戶激活它，最后將其發(fā)布給所有用戶。這樣，我們可以從越來越挑剔的用戶群體那里獲得關于變更的反饋。如果更改出錯（并且在某些時候會出錯）影響就很小，因為只有一小部分用戶組會受到它的影響。而且，該標志可以快速關閉。
布魯克定律
解釋
在經(jīng)典著作《人月神話》中，弗雷德·布魯克 (Fred Brook) 有句名言：為延期的項目增加人力會使項目延期更多。
盡管本書討論的是軟件項目，但它適用于大多數(shù)類型的項目，甚至是軟件開發(fā)之外的項目。
添加人員不會提高項目速度的原因是項目的通信開銷隨著添加到項目中的每個人呈指數(shù)增長。2 個人有 1 條通信路徑，5個人已經(jīng)有 5! = 120 條可能的通信路徑。新人安頓下來并確定他們需要的溝通路徑需要時間，這就是為什么在項目中添加新人時，遲到的項目會更晚。
在軟件開發(fā)中的應用
很簡單。改變截止日期，而不是在已經(jīng)延期的項目中增加人力。
對于向軟件項目中增加新人的期望要切合實際。將人員添加到項目中可能會在某個時候提高速度，但并非總是如此，當然也不是立竿見影。人員和團隊需要時間來適應日常工作，而在某些時候，工作無法充分并行化，因此增加更多人是沒有意義的。 仔細考慮一個新人應該完成什么任務，以及在將該人添加到項目中時您期望什么。
波斯特定律
解釋
波斯特定律也被稱為穩(wěn)健性原則，它指出你應該“在你所做的事情上保守，在你接受別人的事情上自由”。
換句話說，您可以接受多種不同形式的數(shù)據(jù)，以使您的軟件盡可能靈活，但您在處理這些數(shù)據(jù)時應該非常小心，以免因無效或惡意數(shù)據(jù)而損害您的軟件。
在軟件開發(fā)中的應用
該定律源于軟件開發(fā)，因此非常適于直接使用。
為了增強健壯性，您的軟件與其他軟件或人之間的接口應允許不同形式的輸入：
為了向后兼容，新版本的接口應該接受舊版本和新版本的數(shù)據(jù)，
為了更好的用戶體驗，UI 中的表單應該接受不同格式的數(shù)據(jù)，這樣用戶就不必擔心格式。
但是，如果我們愿意接受不同格式的數(shù)據(jù)，我們在處理這些數(shù)據(jù)時就必須保守。我們必須審查無效值，并確保我們不會因為允許太多不同的格式而損害系統(tǒng)的安全性。SQL 注入是一種可能的攻擊，它是通過對用戶輸入過于寬松而啟用的。
克?；舴蛟?/h1>解釋
克希霍夫原理指出，加密系統(tǒng)應該是安全的，即使它的方法是公知的。只有您用來解密某些東西的密鑰才需要是私有的。
在軟件開發(fā)中的應用
這很簡單，真的。永遠不要相信要求其方法是私有的加密系統(tǒng)。這被稱為“隱藏的安全”。像這樣的系統(tǒng)本質上是不安全的。一旦該方法向公眾公開，它就容易受到攻擊。
相反，依靠公開審查和可信的對稱和非對稱加密系統(tǒng)，這些系統(tǒng)是在可以公開審查的開源包中實現(xiàn)的。每個想知道他們內部如何工作的人都可以查看代碼并驗證它們是否安全。
萊納斯定律
解釋
在關于 Linux 內核開發(fā)的《教堂與集市》一書中，埃里克·雷蒙德 (Eric Raymond) 寫道：“只要有足夠的眼光，所有 bug 都是微不足道的”。他將此稱為“萊納斯定律”以紀念萊納斯·托瓦茲。
意思是，如果很多人看代碼，那么相比很少人看代碼而言，可以更好地揭露代碼中的錯誤。
在軟件開發(fā)中的應用
如果您想擺脫 bug，請讓其他人查看您的代碼。
源于開源社區(qū)的一種常見做法是讓開發(fā)人員提出包含代碼更改的拉取請求（pull request），然后讓其他開發(fā)人員在將拉取請求合并到主分支之前審查該拉取請求。這種做法也進入了閉源開發(fā)，但根據(jù) Linus 定律，拉取請求在閉源環(huán)境（只有少數(shù)人查看它）中的作用不如在開源環(huán)境中（其中 可能很多貢獻者都在看它）。
其他為代碼添加更多眼球的做法是結對編程和群體編程。至少在閉源環(huán)境中，這些在避免錯誤方面比拉取請求審查更有效，因為每個人都參與了代碼的初始階段，這為每個人提供了更好的上下文來理解代碼和潛在的錯誤。
沃斯定律
解釋
沃斯定律指出，軟件變慢的速度比硬件變快的速度要快。
在軟件開發(fā)中的應用
不要依賴強大的硬件來運行性能不佳的代碼。相反，代碼要加強性能優(yōu)化。
這必須與 [[軟件開發(fā)定律#Knuth 的優(yōu)化原則]] 的格言相平衡，該格言說“過早的優(yōu)化是萬惡之源”。要把精力花在為用戶構建新功能上，而不是用于代碼的性能優(yōu)化上。
通常，這是一種平衡的藝術。
克努斯優(yōu)化原則
解釋
唐納德·克努斯 (Donald Knuth) 在他的一部作品中寫下了“過早優(yōu)化是萬惡之源”這句話，這句話經(jīng)常斷章取意，并被用作根本不關心優(yōu)化代碼的借口。
在軟件開發(fā)中的應用
根據(jù)克努斯定律，我們不應該浪費精力過早地優(yōu)化代碼。然而，根據(jù)沃斯定律，我們也不應該依賴硬件足夠快來執(zhí)行未經(jīng)優(yōu)化的代碼。
最后，這就是我從這些原則中得出的結論：
優(yōu)化可以輕松完成且不需要太多努力的代碼：例如，編寫幾行額外代碼以避免經(jīng)歷可能有很多項的循環(huán)
優(yōu)化一直在執(zhí)行的代碼路徑中的代碼
除此之外，不要在優(yōu)化代碼上花太多精力，除非你已經(jīng)確定了一個性能瓶頸。
保持懷疑
定律和原則是好的。它允許我們從某個角度評估某些情況，如果沒有它們，我們可能不會有這些情況。
然而，盲目地將法律和原則應用于每種情況是行不通的。每一種情況都會帶來微妙的變化，這可能意味著某個原則不能或不應該被應用。
對你遇到的原則和定律保持懷疑。世界并不是非黑即白的。
本文譯自：?[Laws and Principles of Software Development - Reflectoring](
https://reflectoring.io/laws-and-principles-of-software-development/)
