溫馨提示: 原文中含有很多外部連結，點擊全文左下角的"閱讀原文"體驗會更佳喔~
來源:
nusr/hacker-laws-zh
這是hacker-laws (https://github.com/dwmkerr/hacker-laws) 的的中文翻譯，對開發人員有用的定律，理論，原則和模式(Laws, Theories, Principles and Patterns that developers will find useful.)。
為了方便閱讀，維基百科增加了中文連結！
英文連結表示 hacker-laws 項目尚未完成。
國內無法訪問維基百科說明
喜歡點 star ，關注點 watch，貢獻點 fork 。
介紹當談論到開發時，人們會談到許多定律。 這個倉庫收錄了一些最常見的定律。請分享這個倉庫並提交 PR ！
❗: 這個倉庫包含對一些定律、原則以及模式的解釋，但不提倡其中任何一個。 它們的應用始終存在著爭論，並且很大程度上取決於你正在做什麼。
定律現在我們開始吧！
阿姆達爾定律 (Amdahl's Law)阿姆達爾定律是一個顯示計算任務潛在加速能力的公式。這種能力可以通過增加系統資源來實現。 通常用於並行計算中，它可以預測增加處理器數量的實際好處。增加處理器數量會受到程序並行性的限制。
舉例說明：如果程序由兩部分組成，部分 A 必須由單個處理器執行，部分 B 可以並行運行，那麼我們向執行程序的系統添加多個處理器只能獲得有限的好處。 它可以極大地提升部分 B 的運行速度，但部分 A 的運行速度將保持不變。
下圖展示了運行速度的潛能：
_(圖片來源: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)_
可以看出，50％ 並行化的程序僅僅受益於 10 個處理單元，而 95％ 並行化的程序可以通過超過一千個處理單元顯著提升速度。
隨著摩爾定律減慢，以及單個處理器的速度增加緩慢，並行化是提高性能的關鍵。 圖形編程是一個很好的例子，現代著色器可以並行渲染單個像素或片段。這也是為什麼現代顯卡通常具有數千個處理核心（GPU 或著色器單元）的原因。
參見：
布魯克斯法則 (Brooks's Law)布魯克斯是《人月神話》的作者。
軟體開發後期，添加人力只會使項目開發得更慢。
這個定律表明，在許多情況下，試圖通過增加人力來加速延期項目的交付，將會使項目交付得更晚。 布魯克斯也明白，這是一種過度簡化。但一般的推理是，新資源的增加時間和通信開銷，會使開發速度減慢。 而且，許多任務是不可分的，比如更多的資源容易分配，這也意味著潛在的速度增加也更低。
諺語 九個女人不能在一個月內生一個孩子 與布魯克斯法則同出一轍，特別是某些不可分割或者並行的工作。
參見：
康威定律 (Conway's Law)系統的技術邊界受制於組織的結構。在改進組織時，通常會提到它。康威定律表明，如果一個組織被分散成許多小型、無聯繫的單元，那麼它開發的軟體也是小而分散的。 如果一個組織更多地垂直建立在特性或服務周圍，那麼軟體系統也會反映這一點。
參見：
侯世達定律 (Hofstadter's Law)即使考慮到侯世達定律，它也總是比你預期的要長。
在估計需要多長時間時，您可能會聽到此定律。軟體開發中似乎不言而喻，我們往往不能準確地估計需要多長時間才能完成。
技術成熟度曲線 (The Hype Cycle & Amara's Law)我們傾向於過高估計技術在短期內的影響，並低估長期效應。
(羅伊阿馬拉)
技術成熟度曲線是高德納諮詢公司最初製作的技術興起和發展的直觀表現。一圖頂千言：
_(圖片來源: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)_
簡而言之，這個周期表明，新技術及其潛在影響通常會引發一陣浪潮。 團隊快速使用這些新技術，有時會對結果感到失望。 這可能是因為該技術還不夠成熟，或者現實應用還沒有完全實現。 經過一段時間後，技術的能力提高了，使用它的實際機會會增加，最終團隊可以提高工作效率。 羅伊·阿馬拉簡潔地總結了這一點：我們傾向於高估技術短期內的影響，並低估長期效應。
隱式接口定律 (Hyrum's Law)有足夠數量 API 的用戶，
你在合同中的承諾並不重要：
你系統的所有可觀察行為
將取決於某人。
（Hyrum Wright）
隱式接口定律表明，當你擁有足夠數量的 API 用戶時，API 的所有行為（即使那些未被定義為公共說明的一部分）最終都會被某人所依賴。 一個簡單的例子，例如 API 的響應時間這種非功能性因素。 一個更微妙的例子是：用戶使用正則表達式判斷錯誤信息的類型。 即使 API 的公共說明沒有說明消息的內容，來指示用戶錯誤的類型。一些用戶可能會使用該消息，並且更改消息，實際上會破壞用戶的 API。
參見：
摩爾定律 (Moore's Law)集成電路中的電晶體數量大約每兩年翻一番。
通常用於說明半導體和晶片技術提高的絕對速度。從 20 世紀 70 年代到 21 世紀後期，摩爾的預測被證明是高度準確的。 近年來，這種趨勢略有變化，部分原因受到[量子隧穿效應]（https://zh.wikipedia.org/wiki/%E9%87%8F%E5%AD%90%E7%A9%BF%E9%9A%A7%E6%95%88%E6%87%89）影響。 然而，並行化計算的進步以及半導體技術和量子計算潛在的革命性變化，可能意味著摩爾定律在未來幾十年內繼續保持正確。
帕金森定理 (Parkinson's Law)在工作能夠完成的時限內，工作量會一直增加，直到所有可用時間都被填充為止。
基於官僚機構的研究背景，該定律被應用於軟體開發中。該理論認為，團隊在截止日期之前效率低下，然後在截止日期前趕緊完成工作，從而使實際截止日期有些隨意。
將這個定理與[侯世達定律]（#侯世達定律）相結合，則會獲得更加悲觀的觀點： 工作將擴大以填補所需時間，並且需要比預期更長的時間。
參見：
普特定律 (Putt's Law)技術由兩類人主導，一類是管理人員， 一類是技術人員。
普特定律常常遵循普特推論：
每個技術層次都會發展地逆轉。
這些結論表明，由於各種選擇標準和群體組織的趨勢，技術組織的工作層面將有一些技術人員，以及一些不了解複雜性和挑戰的管理人員。 這種現象可能是由於 The Peter Principe 或者 Dilbert's Law 造成的。
但是，應該強調的是，諸如此類的定律是一種廣泛的概括，可能適用於某些類型的組織，而不適用於其他組織。
參見：
The Peter Principe
Dilbert's Law.
複雜性守恆定律 (The Law of Conservation of Complexity)該定律表明系統中存在著一定程度的複雜性，並且不能減少。
系統中的某些複雜性是無意的。 這是由於結構不良，錯誤或者糟糕的建模造成的。 可以減少以及消除無意的複雜性。 然而，由於待解決問題固有的複雜性，某些複雜性是內在的。 這種複雜性可以移動，但不能消除。
一個該定律的有趣元素是，即使簡化整個系統，內在的複雜性也不會降低。它會移動到用戶，並且用戶必須以更複雜的方式行事。
漏洞抽象定律 (The Law of Leaky Abstractions)在某種程度上，所有非平凡的抽象都是漏洞。
(喬爾斯 波爾斯基)
該定律指出，通常用於簡化複雜系統的抽象，某些情況下將在底層系統有漏洞，這使得抽象表現為意外的方式。
例如加載文件並讀取其內容。 文件系統 API 是較低級別內核系統的抽象，它們本身是與磁碟（或 SSD 的快閃記憶體）上的數據更改相關的物理過程抽象。 在大多數情況下，處理文件（如二進位數據流）的抽象將起作用。 但是，對於磁碟驅動器，順序讀取數據將比隨機訪問快得多（由於頁面錯誤的開銷增加）。但對於 SSD 驅動器，此開銷不會出現。 需要理解基礎細節來處理這種情況（例如，資料庫索引文件的良好結構可以減少隨機訪問的開銷），開發人員需要合理的抽象，來處理不同的細節。
當引入的抽象更多時，上面的例子會變得更複雜。 Linux 作業系統允許通過網絡訪問文件，但在本地表示為普通文件。 如果存在網絡故障，這種抽象將有漏洞。 如果開發人員將這些文件視為普通文件，而不考慮它們可能會受到網絡延遲和故障的影響，那麼解決方案就會出錯。
描述該定律的文章表明，過度依賴抽象，加上對底層過程的理解不足，實際上使得問題在某些情況下更加複雜。
參見：
真實的例子：
帕金森瑣碎定理 (The Law of Triviality)該定理顯示，群體將給予更多的時間和注意力來處理瑣碎的問題，而不是用來處理嚴肅而實質性的問題。
常見的虛構例子是委員會批准核電站的計劃，他們大部分時間都在討論自行車棚的結構，而不是電廠本身等更為重要的設計。 如果沒有大量的專業知識或者準備，很難給非常大的複雜主題討論提供寶貴的意見。 但是，人們希望看到寶貴的意見。 因此，傾向於將過多的時間集中在小細節上，這很容易推理，但不一定特別重要。
上面的虛構例子導致使用Bike Shedding這個詞，作為在瑣碎細節上浪費時間的表達。
Unix 哲學 (The Unix Philosophy)Unix 哲學是軟體組件應該很小，並專注於做一件特定的事情。 將小型、簡單以及定義良好的單元組合在一起，而不是使用大型、複雜以及多用途程序，可以更輕鬆地構建系統。
像微服務架構這種現代實踐可以被認為是這種哲學的應用，其中服務很小，集中於做一件特定的事情，由簡單的構建塊組成複雜的行為。
Spotify 模型 (The Spotify Model)Spotify 模型是團隊和組織結構的一種方法，已被 Spotify 實驗室推廣。 在此模型中，團隊圍繞功能而非技術進行組織。
Spotify 模型還普及了部落、行會以及章節的概念，這些是其組織結構的其他組成部分。
沃德勒定律 (Wadler's Law)任何語言設計中，討論下面列表中某個要素所花費的總時間與其位置上的兩個要素成正比。
語義
語法
詞法
評論詞法
（簡而言之，對於語義上花費的每一個小時，將在評論詞法上花費 8 小時）。
與 帕金森瑣碎定理 類似, 沃德勒定律指出，在設計語言時，與這些特徵的重要性相比，花在語言結構上的時間相當多。
參見：
原則原則通常是與設計相關的準則。
魯棒性原則 (The Robustness Principle)對自己所做的事情要保守，對自己接受的人要寬容。
通常應用於伺服器應用程式開發中，該原則指出，你發送給其他人的內容應儘可能小且符合要求，並且處理不符合要求的輸入。
該原則的目標是構建穩健的系統。如果可以理解意圖，它們可以處理不良的輸入。 但是，接受錯誤格式的輸入可能存在安全隱患，特別是此類的輸入未經過充分測試。
SOLID這是一個縮寫，指的是：
S：單一功能原則 (The Single Responsibility Principle)
O：開閉原則 (The Open/Closed Principle)
L：裡氏替換原則 (The Liskov Substitution Principle)
I：接口隔離原則 (The Interface Segregation Principle)
D：依賴反轉原則 (The Dependency Inversion Principle)
這些是 Object-Oriented Programming 的關鍵原則。 諸如此類的設計原則能夠幫助開發人員構建更易於維護的系統。
單一功能原則 (The Single Responsibility Principle)每個模塊或者類只應該有一項功能。
SOLID 的第一個原則。 這個原則表明模塊後者類只應該做一件事。 實際上，這意味著對程序功能的單個小更改，應該只需要更改一個組件。 例如，更改密碼驗證複雜性的方式應該只需要更改程序的一部分。
理論上講，這使代碼更健壯，更容易更改。 知道正在更改的組件只有一個功能，這意味著測試更改更容易。 使用前面的例子，更改密碼複雜性組件應該只影響與密碼複雜性相關的功能。 變更具有許多功能的組件可能要困難得多。
參見：
開閉原則 (The Open/Closed Principle)實體應開放擴展並關閉修改。
SOLID 的第二個原則。 這個原則指出實體（可以是類，模塊，函數等）應該能夠使它們的行為進行擴展，但是它們的擴展行為不應該被修改。
舉一個假設的例子，想像一個能夠將 Markdown 轉換為 HTML 的模塊。 如果可以擴展模塊以處理新的 markdown 特徵，而無需修改內部模塊，則可以認為是開放擴展。 如果用戶不能修改模塊以處理現有的 Markdown 特徵，那麼它被認為是關閉修改。
這個原則與面向對象編程緊密相關，我們可以設計對象以便於擴展，但是可以避免以意想不到的方式改變其現有對象的行為。
參見：
裡氏替換原則 (The Liskov Substitution Principle)可以在不破壞系統的情況下，用子類型替換類型。
SOLID 的第三個原則。 該原則指出，如果組件依賴於類型，那麼它應該能夠使用該類型的子類型，而不會導致系統失敗或者必須知道該子類型的詳細信息。
舉個例子，假設我們有一個方法，讀取 XML 文檔。 如果該方法使用基類型 file，則從 file 派生的任何內容，都能用在該方法中。 如果 file 支持反向搜索，並且 xml 解析器使用該函數，但是派生類型 network file 嘗試反向搜索時失敗，則 network file 將違反該原則。
該原則與面向對象編程特別有關，必須仔細建模類型層次，以避免混淆系統用戶。
參見
接口隔離原則 (The Interface Segregation Principle)不應該強迫客戶端依賴它不使用的方法。
SOLID 的第四個原則。 該原則指出組件的消費者不應該依賴於它實際上不使用的組件功能。
舉一個例子，假設我們有一個方法，讀取 XML 文檔。 它只需要讀取文件中的字節，向前移動或向後移動。 如果由於文件結構不相關（例如更新文件安全性的權限模型），需要更新此方法，則原則已失效。 文件最好實現 搜索流 接口，並讓 XML 讀取器使用它。
該原則與面向對象編程緊密相關，其中接口，層次結構和抽象類型用於不同組件的 minimise the coupling。 Duck typing 是一種通過消除顯式接口來強制執行該原則的方法。
參見
依賴反轉原則 (The Dependency Inversion Principle)高級模塊不應該依賴於低級實現。
SOLID 的第五個原則。 該原則指出，更高級別的協調組件不應該知道其依賴關係的細節。
舉個例子，假設我們有一個從網站讀取元數據的程序。我們假設主要組件必須知道下載網頁內容的組件，以及可以讀取元數據的組件。如果我們考慮依賴反轉，主要組件將僅依賴於可以獲取字節數據的抽象組件，然後是一個能夠從字節流中讀取元數據的抽象組件。主要組件不需要了解 TCP、IP、HTTP、HTML 等。
這個原則很複雜，因為它似乎可以反轉系統的預期依賴性（因此得名）。實踐中，這也意味著，單獨的編排組件必須確保抽象類型的正確實現被使用（例如在前面的例子中，必須提供元數據讀取器組件、HTTP 文件下載功能和 HTML 元標籤讀取器）。然後，這涉及諸如 Inversion of Control 和 Dependency Injection 之類的模式。
參見：
TODO嗨！如果你讀到這裡，點擊了一個我尚未編寫的主題連結，我感到抱歉。 這是正在進行中的工作！
隨意提 Issue 獲取更多詳細信息，或者 Pull Request 提交你提議的主題。
原文地址：
https://www.cnblogs.com/enjoy233/p/github_hacker_laws_Chinese.html
更多精彩文章, 歡迎訪問本人博客https://enjoy233.cnblogs.com 或 知乎搜索「Bravo Yeung」.
歡迎轉發到朋友圈, 公眾號轉載請後臺聯繫本人申請授權~
回復m可查看本號文章列表噢, 然後可以點擊連結閱讀文章~
也可在收到的列表中找到文章相應編號後回後臺回復編號直達.
推薦閱讀
中英文電子書下載網站大搜羅
英語語法工具 | 那些可以糾正英語文章中語法的神器們
開發者見聞 | ASP.NET Core開發者路線圖
點擊"在看"的人，
2019都會變得特別好看👇