大家好，我是你們的 前端章魚貓，一個不喜歡前端、又不喜歡吃魚的超級貓 ~

當(dāng)程序員談?wù)撻_發(fā)設(shè)計時，常常會聊到非常多的定律，而 GitHub 上的一個名為「hacker-laws」的倉庫收錄了一些最常見的定律、原則等，獲得了 16.5k 的 Star。

還記得所有AI教程必提的「奧卡姆剃刀原則」嗎？即：如無必要，勿增實體。

這條原則也被收藏，還有一些不太常見的費茨法則、蓋爾定律、康威定律等，都被一一收入囊中。

寫代碼累了困了？這些法則讓工作事半功倍。

前端 GitHub 地址：https://github.com/biaochenxuying/FrontEndGitHub

以下為【前端GitHub】的第 3 期內(nèi)容。

定律

90-9-1 法則（1% 法則）

90-9-1 法則表明，在諸如維基這樣的互聯(lián)網(wǎng)社區(qū)中，90% 的用戶只看內(nèi)容并不參與互動，9% 的用戶會參與討論，而只有 1% 的用戶會創(chuàng)造內(nèi)容。

現(xiàn)實世界的例子：2014 年，對四個健康的數(shù)字社交網(wǎng)絡(luò)進行的一項研究發(fā)現(xiàn)，排名前 1% 的人創(chuàng)造了 73% 的帖子，緊隨其后的 9% 平均占 25%，其余的 90% 的人平均占 2%。

類似的，帕累托法則也指出：生活中大多數(shù)事情不是均勻分布的。這個原則也被稱為二八法則，重要的少數(shù)法則和因素稀疏原則。

帕累托法則 (The Pareto Principle or The 80/20 Rule)

生活中大多數(shù)事情不是均勻分布的。

帕累托法則可以幫你認識到大多數(shù)結(jié)果來自少數(shù)投入：

• 某個軟件的 80％ 代碼只占了總分配時間的 20％（相反，最難的 20％ 代碼部分占用了 80％ 的時間）

• 20％ 的努力產(chǎn)生了 80％ 的結(jié)果

• 20％ 的工作創(chuàng)造了 80％ 的收入

• 20％ 的錯誤導(dǎo)致了 80％ 的崩潰

• 20％ 的功能導(dǎo)致了 80％ 的使用量

在 20 世紀(jì) 40 年代，公認為質(zhì)量控制之父的美國羅馬尼亞工程師約瑟夫·朱蘭博士，開始將帕累托法則應(yīng)用于質(zhì)量問題。

這個原則也被稱為二八法則，重要的少數(shù)法則和因素稀疏原則。

現(xiàn)實的例子：

• 微軟 2002 年的報告表明，修復(fù)最常出現(xiàn)的 20％ 錯誤，將消除 Windows 和 Office 中 80％ 的 錯誤和崩潰。

彼得原理 (The Peter Principle)

在等級制度中，人往往會被提升到他們的“無法勝任的水平”。

這是由勞倫斯·彼得提出的一個管理概念。彼得原理認為，擅長工作的人會得到提升，直到他們達到不再成功的水平 (即他們所“無法勝任的水平”)。基于此，由于他們資歷更高，被公司開除的可能性較小 (除非他們表現(xiàn)非常糟糕)。而且他們將繼續(xù)擔(dān)任幾乎沒有本職技能的職位，即使那些原本讓他們成功的能力在新工作中并無必要。

有的工程師對此特別感興趣，它們最初從事的是深度的技術(shù)工作，但走上了管理其他工程師的職業(yè)道路——這意味著需要一個完全不同的技能樹。

技術(shù)成熟度曲線法則

技術(shù)成熟度曲線是高德納咨詢公司對技術(shù)最初興起和發(fā)展的視覺展現(xiàn)。一圖勝千言：

簡而言之，這個曲線表明，新技術(shù)及其潛在影響通常會引發(fā)一輪浪潮。

團隊快速使用這些新技術(shù)，但有時會對結(jié)果感到失望，這可能是因為該技術(shù)還不夠成熟，或者現(xiàn)實應(yīng)用還沒有完全實現(xiàn)。

經(jīng)過一段時間后，技術(shù)的能力提高了，使用它的實際機會會增加，最終團隊也可以提高工作效率。

羅伊·阿馬拉簡潔地總結(jié)了這一點：我們傾向于高估技術(shù)短期內(nèi)的影響，并低估其長期效應(yīng)。

破窗效應(yīng)

在破窗理論中認為，一些明顯的犯罪跡象(或缺乏環(huán)保意識)會導(dǎo)致進一步的、更嚴(yán)重的犯罪(或環(huán)境的進一步惡化)。

破窗理論已應(yīng)用于軟件開發(fā)中，它表明劣質(zhì)代碼可能會影響后續(xù)優(yōu)化的效率，從而進一步造成代碼劣化；隨著時間的推移，這種效應(yīng)將會導(dǎo)致代碼質(zhì)量大幅下降。

沒那么常見的法則，但也暗藏工作秘訣

阿姆達爾定律

阿姆達爾定律是一個顯示計算任務(wù)潛在加速能力的公式。這種能力可以通過增加系統(tǒng)資源來實現(xiàn)，通常用于并行計算中。

它可以預(yù)測增加處理器數(shù)量的實際好處，然而增加處理器數(shù)量會受到程序并行性的限制。

舉例說明：如果程序由兩部分組成，A部分必須由單個處理器執(zhí)行，B部分可以并行運行。那么向執(zhí)行程序的系統(tǒng)添加多個處理器只能獲得有限的好處。

它可以極大地提升部分 B 的運行速度，但部分 A 的運行速度將保持不變。

下圖展示了一些運行速度的提升潛能的例子：

可以看出，50％ 并行化的程序在使用大于 10 個處理單元之后的速度提升收效甚微，而 95％ 并行化的程序在使用超過一千個處理單元之后仍然可以顯著提升速度。

隨著摩爾定律逐漸失效，單個處理器的速度增加緩慢，并行化是提高性能的關(guān)鍵。

圖形編程是一個極好的例子，現(xiàn)代著色器可以并行渲染單個像素或片段。這也是現(xiàn)代顯卡通常具有數(shù)千個處理核心（GPU 單元）的原因。

林納斯定律

足夠多的眼睛，就可讓所有問題浮現(xiàn)。

簡單地說，能夠看到問題的人越多，有人解決過相關(guān)的問題或事情的可能性就越高。

最初該定律是用來描述開源模型對于項目的價值的，并適用于任意的軟件項目。同時它也可以擴展到開發(fā)流程之中——更多的代碼審查、更多的靜態(tài)分析和多重測試可以讓問題更加明顯和容易識別。

林納斯定律的一個更正式的說法如下：

如果有足夠大的測試員和聯(lián)合開發(fā)人員基礎(chǔ)，那么幾乎每個問題都能很快被特征化，從而讓以前遇到過類似問題的人解決。

德墨忒爾定律

得墨忒耳定律又稱最少知識原則，是一條與面向?qū)ο笳Z言有關(guān)的軟件設(shè)計原則。

該定律表明，軟件的一個單元應(yīng)該只與其直接合作者交談。

比如對象 A 引用了對象 B，對象 B 引用了對象 C，則 A 可以直接調(diào)用 B 的方法，但不應(yīng)直接調(diào)用 C 的方法。所以如果 C 有一個 dothing()?的方法，A 不應(yīng)該直接調(diào)用，而是用 B.getC().doThis()。

遵循這一定律可以限制代碼更改的范圍，使其以后更容易維護、更安全。

墨菲定律 (Murphy's Law / Sod's Law)

凡是可能出錯的事就一定會出錯。

墨菲定律?說明了如果一件事有可能出錯，那么就一定會出錯。

這是一句開發(fā)人員間的俗語，在開發(fā)、測試甚至在生產(chǎn)中都有可能會發(fā)生一些令人意想不到的事情。而這一定律也可以參考在英式英語中更為常見的?索德定理?：

如果某件事可能出錯，那么它一定會在最糟糕的時候發(fā)生。

奧卡姆剃刀 (Occam's Razor)

如無必要，勿增實體。

奧卡姆剃刀指出，在幾種可能的解決方案之中，最有可能的解決方案便是概念和假設(shè)最少的那個。因為這個解決方案最為簡單，只解決了問題，并且沒有引入額外的復(fù)雜度和可能的負面后果。

坎寧漢姆定律

在網(wǎng)絡(luò)上想得到正確答案的最好方法不是提問題，而是發(fā)布一個錯誤的答案。

帕金森定理 (Parkinson's Law)

在工作能夠完成的時限內(nèi)，工作量會一直增加，直到所有可用時間都被填滿為止。

基于官僚機構(gòu)的研究背景，該定律被應(yīng)用于軟件開發(fā)中。該理論認為，團隊在截止日期之前效率低下，然后在截止日期前趕緊完成工作，從而使實際截止日期變得隨意。

將這個定理與侯世達定律相結(jié)合，則會獲得更加悲觀的觀點：為了在規(guī)定時間內(nèi)完成工作，工作將增多，花費比預(yù)期更長的時間。

職場相關(guān)的原則

除了以上的這些法則，該倉庫還給出了很多的原則。

死海效應(yīng)原則

"... 那些更有才華，更有效率的 IT 工程師最有可能離開——消失 ... （而那些傾向于）留下來的“剩下的人”——是最沒有才華和效率的 IT 工程師。"

死海效應(yīng)表明，在任何一個組織中，工程師的技能、才華和效能往往與他們在公司的時間呈反比。

通常情況下，技術(shù)好的工程師很容易在其他的地方找到工作，并且他們往往也會這樣做。而技能過時或技術(shù)薄弱的工程師則會留在公司，因為其他地方很難找到工作。如果這些工程師在公司里獲得了加薪，他們會更愿意留在公司，因為在其他地方找到同等薪酬的工作會很有挑戰(zhàn)性。

呆伯特原則

公司會傾向于系統(tǒng)地將工作能力差的員工提升到管理層，以使他們脫離工作流程，從而限制他們所能造成的損害。

技術(shù)相關(guān)的原則

單一功能原則

每個模塊或者類只應(yīng)該有一項功能。

SOLID 的第一個原則。這個原則表明模塊或者類只應(yīng)該做一件事。實際上，這意味著對程序功能的單個小更改，應(yīng)該只需要更改一個組件。例如，更改密碼驗證復(fù)雜性的方式應(yīng)該只需要更改程序的一部分。

理論上講，這使代碼更健壯，更容易更改。知道正在更改的組件只有一個功能，這意味著測試更改更容易。使用前面的例子，更改密碼復(fù)雜性組件應(yīng)該只影響與密碼復(fù)雜性相關(guān)的功能。變更具有許多功能的組件可能要困難得多。

開閉原則

實體應(yīng)開放擴展并關(guān)閉修改。

SOLID 的第二個原則。這個原則指出實體（可以是類、模塊、函數(shù)等）應(yīng)該能夠使它們的行為易于擴展，但是它們的擴展行為不應(yīng)該被修改。

舉一個假設(shè)的例子，想象一個能夠?qū)?Markdown 轉(zhuǎn)換為 HTML 的模塊。如果可以擴展模塊，而不修改內(nèi)部模塊來處理新的 markdown 特征，而無需修改內(nèi)部模塊，則可以認為是開放擴展。如果用戶不能修改處理現(xiàn)有 Markdown 特征的模塊，那么它被認為是關(guān)閉修改。

這個原則與面向?qū)ο缶幊叹o密相關(guān)，讓我們可以設(shè)計對象以便于擴展，但是可以避免以意想不到的方式改變其現(xiàn)有對象的行為。

里氏替換原則

可以在不破壞系統(tǒng)的情況下，用子類型替換類型。

SOLID 的第三個原則。該原則指出，如果組件依賴于類型，那么它應(yīng)該能夠使用該類型的子類型，而不會導(dǎo)致系統(tǒng)失敗或者必須知道該子類型的詳細信息。

舉個例子，假設(shè)我們有一個方法，讀取 XML 文檔。如果該方法使用基類型?file，則從?file?派生的任何內(nèi)容，都能用在該方法中。如果?file?支持反向查找，并且 xml 解析器使用該函數(shù)，但是派生類型?network file?嘗試反向查找時失敗，則?network file?將違反該原則。

該原則與面向?qū)ο缶幊叹o密相關(guān)，必須仔細建模、層次結(jié)構(gòu)，以避免讓系統(tǒng)用戶混淆。

接口隔離原則

不應(yīng)強制任何客戶端依賴于它不使用的方法。

SOLID 的第四個原則。該原則指出組件的消費者不應(yīng)該依賴于它實際上不使用的組件函數(shù)。

舉一個例子，假設(shè)我們有一個方法，讀取 XML 文檔。它只需要讀取文件中的字節(jié)，向前移動或向后移動。如果由于一個與文件結(jié)構(gòu)不相關(guān)的功能發(fā)生更改（例如更新文件安全性的權(quán)限模型），需要更新此方法，則該原則已失效。文件最好實現(xiàn)?可查詢流?接口，并讓 XML 讀取器使用該接口。

該原則與面向?qū)ο缶幊叹o密相關(guān)，其中接口，層次結(jié)構(gòu)和抽象類型用于不同組件的 minimise the coupling。Duck typing 是一種通過消除顯式接口來強制執(zhí)行該原則的方法。

依賴翻轉(zhuǎn)原則

高級模塊不應(yīng)該依賴于低級實現(xiàn)。

SOLID 的第五個原則。該原則指出，更高級別的協(xié)調(diào)組件不應(yīng)該知道其依賴項的詳細信息。

舉個例子，假設(shè)我們有一個從網(wǎng)站讀取元數(shù)據(jù)的程序。我們假設(shè)主要組件必須知道下載網(wǎng)頁內(nèi)容的組件，以及可以讀取元數(shù)據(jù)的組件。如果我們考慮依賴反轉(zhuǎn)，主要組件將僅依賴于可以獲取字節(jié)數(shù)據(jù)的抽象組件，然后是一個能夠從字節(jié)流中讀取元數(shù)據(jù)的抽象組件，主要組件不需要了解 TCP、IP、HTTP、HTML 等。

這個原則很復(fù)雜，因為它似乎可以反轉(zhuǎn)系統(tǒng)的預(yù)期依賴性（因此得名）。實踐中，這也意味著，單獨的編排組件必須確保抽象類型的正確實現(xiàn)被使用（例如在前面的例子中，必須提供元數(shù)據(jù)讀取器組件、HTTP 文件下載功能和 HTML 元標(biāo)簽讀取器）。然后，這涉及諸如 Inversion of Control 和 Dependency Injection 之類的模式。

切斯特森圍欄 (Chesterson's Fence)

在了解現(xiàn)有情況背后的原因之前，不應(yīng)該進行改進。

該原則與軟件工程中的消除技術(shù)負債 (Technical debt) 相關(guān)。程序的每一行最初都是出于某種原因編寫的，因此根據(jù)切斯特森圍欄原則，在更改或刪除代碼之前，即使看起來似乎是多余的或不正確的，也應(yīng)該嘗試完全理解代碼的上下文和含義。

該原則的名字來源于一則故事。一個男人橫穿馬路中央的柵欄，他向市長抱怨這道柵欄沒有用還擋路，并要求拆除它。市長問他為什么要在那里建柵欄，那個人回答說不知道。市長接著說：“如果你不知道它的用途，我肯定不會讓你把它拆了。你去查查它的用途，之后我可能會允許你拆掉它。”

哲學(xué)意味的原則

魯棒性原則

在自己所做的事情上要保守, 在接受別人的事情上要自由。

通常應(yīng)用于服務(wù)器應(yīng)用程序開發(fā)中，該原則指出，你發(fā)送給其他人的內(nèi)容應(yīng)盡可能最小且符合要求，并且處理不符合要求的輸入。

該原則的目標(biāo)是構(gòu)建穩(wěn)健的系統(tǒng)。如果可以理解意圖，它們可以處理不良的輸入。但是，接受錯誤格式的輸入可能存在安全隱患，特別是此類的輸入未經(jīng)過充分測試。

不要重復(fù)你自己原則

系統(tǒng)中，每一塊知識都必須是單一、明確而權(quán)威的。

DRY 是 Do not Repeat Yourself 的縮寫。這個原則旨在幫助開發(fā)人員減少代碼的重復(fù)性，并將公共代碼保存在一個地方。最初由安德魯·亨特和戴夫·托馬斯在 1999 年出版的《程序員修煉之道》中引用。

與 DRY 相反的是 WET（功能實現(xiàn)兩次或者喜歡打字 Write Everything Twice or We Enjoy Typing）。

實際上，如果你在兩個或更多的地方有相同的功能，你可以使用 DRY 原則將它們合并為一個，并在任何你需要的地方重復(fù)使用。

你不需要它法則

只有當(dāng)你需要某些東西的時候，才去實現(xiàn)它們，而不是在你預(yù)見的時候。

極限編程原則告誡開發(fā)人員，他們應(yīng)該只實現(xiàn)當(dāng)前所需的功能，并避免實現(xiàn)未來需要的功能，僅在必要時才實現(xiàn)。

遵守這一原則可以減小代碼庫大小，同時避免時間和生產(chǎn)力浪費在沒有價值的功能上。

KISS原則

保持簡單和直白。

KISS 原則指明了如果大多數(shù)的系統(tǒng)能夠保持簡單而非復(fù)雜化，那么他們便能夠工作在最佳狀態(tài)。因此，簡單性應(yīng)該是設(shè)計時的關(guān)鍵指標(biāo)，同時也要避免不必要的復(fù)雜度。這個短語最初出自 1960 年的美國海軍飛機工程師凱利 · 約翰遜 (Kelly Johnson)。

這一原則的最好例證便是約翰遜給設(shè)計工程師一些實用工具的故事。那時的他們正面臨著一個挑戰(zhàn)，即他們參與設(shè)計的噴氣式飛機必須能夠讓普通的機械師在戰(zhàn)場上僅僅用這些工具進行維修，因此，“直白”這個詞應(yīng)指的是損壞的事物本身和修復(fù)用工具的復(fù)雜度兩者之間的關(guān)系，而非工程師們自身的能力水平。

最后

還有很多的法則和原則沒有一一指出，需要的小伙伴請點擊下面的鏈接打開查看。

hacker-laws 中文地址：https://github.com/nusr/hacker-laws-zh

前端 GitHub 地址：https://github.com/biaochenxuying/FrontEndGitHub

平時如何發(fā)現(xiàn)好的開源項目，可以看看這篇文章：GitHub 上能挖礦的神仙技巧 - 如何發(fā)現(xiàn)優(yōu)秀開源項目。

覺得有用 ？喜歡就收藏，順便點個贊吧，你的支持是我最大的鼓勵！

在公眾號后臺回復(fù)：電子書 ，可以獲得 160 本前端精華書籍哦。

往期精文

全球最火的WEB開發(fā)學(xué)習(xí)路線！沒有之一！3 天就在GitHub收獲了接近 1w 點贊

GitHub上最火的、最值得前端學(xué)習(xí)的數(shù)據(jù)結(jié)構(gòu)與算法項目！沒有之一

總結(jié)

以上是生活随笔為你收集整理的Github标星1.6W+，程序员不得不知的“潜规则”又火了，早知道就不会秃头了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。