選自GitHub

作者：Dave Kerr

機器之心編譯

當談到開發問題時，人們總會談論各種定律。但對于大多數人來說，總有一些是你不了解的，這個問題就需要使用程序員最喜歡的方法解決了：最近 GitHub 上的一個「定律合集」項目突然登上了趨勢榜第二位，Star 數上千，該項目對一些最常見的定律進行了概括，詳情見下文。

大家都是資深程序員，以后就不要老念叨「真香定律」了。

• 項目鏈接：https://github.com/dwmkerr/hacker-laws

本文包含對一些定律、原則和模式的解釋，但并不主張其中任何一項。是否要應用哪個定律一直是一個爭論性問題，并且很大程度上取決于你在做哪方面的工作。

這些規則目錄如下：

定律

• 阿姆達爾定律

• 布魯克斯法則

• 康威定律

• 侯世達定律

• 炒作周期 & 阿瑪拉定律

• 海勒姆法則

• 帕金森定律

• Putt's Law

• 復雜性守恒定律（泰斯勒定律）

• 抽象漏洞定律

• 帕金森瑣碎定律

• Unix哲學

• The Spotify Model

• Wadler's Law

原則

• 穩健性原則

• SOLID

• 單一功能原則

• 開閉原則

• 里氏替換原則

• 接口隔離原則

• 依賴反轉原則

對于以上如此多的定律和原則，我們選取了其中一些定律和所有的原則進行編譯。現在，先簡單看一下定律吧↓↓

定律

阿姆達爾定律

維基百科：計算機科學界的經驗法則，因吉恩·阿姆達爾而得名。它代表了處理器并行運算之后效率提升的能力。阿姆達爾定律是固定負載（計算總量不變時）時的量化標準。

舉例說明，如果一個程序由兩部分（A和B）組成，A必須有單個處理器執行，B可以并行執行，那么在執行該程序的系統中增加多個處理器帶來的好處是有限的。它可能會大大提升B的速度，但A的速度會保持不變。如下如所示：

從圖中可以看出，一個程序如果只有50%的部分可并行處理，那它使用10個以上處理單元時，處理速度將不會有很大的提升。而一個程序如果有95%的部分可并行處理，即使使用的處理單元超過1000個，其處理速度也會顯著提高。

侯世達定律

維基百科：做事所花費的時間總是比你預期的要長，即使你的預期中考慮了侯世達定律。

當你估計做一件事要花費多長時間時，可能會想到這一定律。軟件開發中的老生常談是，我們往往很難估計交付某個東西所需要的準確時間。

炒作周期 & 阿瑪拉定律

維基百科：我們總是高估一項技術的短期效益，而低估其長期效果。

此定律被描述為鼓勵人們思考科技所能帶來的長期影響的言論。同時，阿瑪拉定律也被人們稱為是對“炒作周期”（技術成熟度曲線）最形象的說明。如下圖所示：

簡言之，這一周期表明，新技術及其潛在影響通常會引起一陣興奮。然后很多團隊快速投入該技術，然后有時會對結果感到失望。這可能是因為技術還不夠成熟，也可能是因為現實應用還沒有完全實現。

經過一段時間后，技術的能力增加，使用技術的實際機會也增加，置身其中的團隊最終開始受益。

海勒姆法則

網絡定義：當一個 API 有足夠多的用戶時，你在約定中承諾什么都無所謂，所有在你系統里面被觀察到的行為都會被一些用戶直接依賴。

海勒姆法則指出，當你的API有非常多的用戶時，API中的所有行為最終都會被某個人所依賴。舉個簡單的例子：非功能性元素，如API的響應時間。稍微復雜一點的例子：依賴對錯誤消息應用正則表達式來確定API錯誤類型的用戶。

摩爾定律

該定律認為，集成電路中的晶體管數量大約每兩年翻一番。

該定律通常用來表示半導體和芯片技術發展的絕對速度。從上世紀70年代到90年代末，摩爾的預測一直非常精準。但近年來，該趨勢已經發生了細微的變化，部分原因在于組件小型化程度受到的物理限制。然而，并行化的發展以及半導體技術和量子計算領域潛在的革命性變化，可能意味著摩爾定律在未來幾十年仍將適用。

復雜性守恒定律（泰斯勒定律）

該定律認為每個系統內都有一定的復雜性不可減少。

系統中的某些復雜性是“不經意的”。可能是由結構不良、錯誤或只是建模不良造成的結果。這些不經意造成的復雜性是可以減少（或消除）的。但是，有些復雜性是“固有的”，是由亟待解決問題的內在復雜性造成的。而這種復雜性可以移動，但無法消除。

這個定律有趣的一點在于，即使簡化整個系統，也無法降低內在的復雜性。這種方法只不過是將復雜性轉移到了用戶一方，然后用戶必須以更復雜的方式行事。

帕金森瑣碎定律

該定律認為，大型組織會花費大量時間和精力來討論無關緊要的瑣事，但是真正重大的決議反而可以輕松過關。

這是因為，在討論非常專業而且金額龐大的事情時，一般人由于缺乏專業知識，不敢隨便發言，以免失言，貽笑大方，因此多半都會肯定（或逃避）該重大方案，而提些與主題無關的雞毛蒜皮小事。相對的，對于簡單的瑣碎小事，由于平常大家都會接觸到而且有相當的認識，反而意見特別多，帕金森稱此現象為瑣碎定律。

Unix 哲學

Unix哲學認為，軟件組件應該很小，而且應該把注意力放在具體的事件上。將小的、簡單的、定義良好的單元組合在一起，而不是使用大的、復雜的、多用途程序，這樣可以使構建系統變得更加容易。

像“微服務架構”這樣的現代實踐就應用了這種哲學。在該架構中，服務很小，且集中做某件事，使得復雜的行為由簡單的構件組成。

Wadler 定律

該定律認為：在任何語言設計中，討論這個列表中某個特性所花費的總時間與它位置的冪成正比。

1.語義

2.語法

3.詞匯語法

4.注釋的詞匯語法

（簡言之，如果在語義上花1小時來討論，那將在注釋語法上花8小時）。

與帕金森瑣碎定律相似，Wadler 定律認為，當設計一種語言時，花在語言結構上的時間與這些特征的重要性相比很不成比例。

原則

在這篇文章中，作者表示原則是指導程序猿開發新應用的一些方針。在碼代碼的過程中，我們經常會遇到各種困難，當然也有各種約定俗成的規則。例如最簡單的命名法，有的默認為使用下劃線、使用小駝峰或大駝峰式的命名，只有了解這些規則，編寫的代碼才是優美的。

穩健性原則

在維基百科中，穩健性原則（Robustness Principle）描述為：“寫代碼要保守，要能接受其它方面的各種信息”。

該原則通常應用于服務器應用的開發，它表示發送的內容應該盡可能少且符合要求。但如果可以處理不符合要求的輸入，那么你的目標應該希望允許各種非一致性的輸入。

該原則的目標是構建一個穩健的系統，對于輸入端，只要對方的意圖仍可以理解，那么我們就應該需要處理非標準格式的輸入。然而，接受格式錯誤的輸入有潛在的安全影響，特別是當這種輸入的處理方式還沒有經過良好的測試。

SOLID

該原則是一個縮寫，即：

• S：單一功能原則

• O：開閉原則

• L：里氏替換原則

• I：接口隔離原則

• D：依賴反轉原則

如上所示， SOLID 指代了和面向對象設計的五個基本原則。當這些原則被一起應用時，它們使得程序員能開發更容易進行軟件維護和擴展的系統。SOLID常應用在測試的驅動開發上，并且是敏捷開發以及自適應軟件開發的基本原則的重要組成部分。下面讓我們看看這5個基本原則都是什么吧。

單一功能原則

在維基百科的描述中，單一功能原則（Single responsibility principle）規定每個類都應該有一個單一的功能，并且該功能應該由這個類完全封裝起來。所有它的（這個類的）服務都應該嚴密的和該功能平行（功能平行，意味著沒有依賴）。

這一原則表明模塊或類應該只完成一件事。這意味著對程序特性的單個小修正，應該只需要在一個組件中進行更改。例如，更改驗證密碼的方式應該只需要更改程序特定的某個模塊。

保持一個類專注于單一功能點，這樣做的重要原因是它會使得類更加穩健。如果我們知道正在修改的組件只有一個功能，那么測試會變得更簡單，新的修改也就好處理了。例如上面，修改密碼驗證應該只影響與密碼驗證相關的特性，如果我們要對具有多功能的模塊進行修改，這樣進行推斷就要復雜多了。

開閉原則

在面向對象的編程中，開閉原則規定：軟件中的對象（類、模塊、函數等等）對于擴展應該是開放的，但是對已存行為的修改是封閉的。這意味著，一個實體需要允許在不改變源代碼的前提下變更它的行為。

該特性在產品化的環境中特別有價值，因為在產品化中改變源代碼需要代碼審查，例如單元測試等方法確保產品使用的質量。遵循這種原則的代碼在擴展時并不發生改變，因此無需上述過程。

舉個栗子，假設某個模塊能夠將 Markdown 文本轉換為HTML。如果模塊可以擴展新的特性，即能處理新提出的Markdown 特性而不修改模塊內部，那么這就表示它對擴展是開放的。

這一原則與面向對象的編程特別相關，我們可以設計易于擴展的對象，但也要避免設計不穩定的對象，因為它們的現有行為可能會以意想不到的方式發生改變。

里氏替換原則

里氏替換原則（Liskov Substitution principle）是對子類型的特別定義。里氏替換原則的內容可以描述為： 派生類（子類）對象可以在程序中代替其基類（父類）對象。也就是說，如果一個模塊依賴于某個類，那么該模塊就需要能使用該類的派生類，且不會發生系統錯誤。

舉個栗子，如果我們有一種方法，它可以從表征文件的結構中讀取XML文本。如果該方法的基類是“file”，那么它能調用從“file”派生的任意類。

這一原則對于面向對象的編程非常重要，我們必須仔細建模類的層次結構，以避免讓系統用戶感到困惑。

接口隔離原則

接口隔離原則（interface-segregation principles）指明用戶（client）應該不依賴于它不使用的方法。接口隔離原則拆分龐大臃腫的接口成為更小的和更具體的接口，這樣用戶將會只需要知道他們感興趣的方法。這種縮小的接口也被稱為角色接口（role interfaces）。接口隔離原則的目的是系統解開耦合，從而容易重構、更改和重新部署。

舉個栗子，假設我們有一種能夠從表征文件的結構中讀取XML文檔的方法。這種方法只需要讀取字節以及在文件中前移或后移即可。如果該方法因為文件結構的一種非相關性特征改變而需要進行更新（如用于表征文件安全的權限模型的更新），則該原則無效。文件最好實現‘seekable-stream’接口并讓XML reader使用。

該原則與面向對象編程具有特殊的相關性，其中接口、層次和抽象類型用于最小化不同組件之間的耦合。鴨子類型（duck typing）通過消除顯式接口來執行該原則。

依賴反轉原則

在傳統的應用架構中，低層次的組件設計用到高層次的組件中，這一點提供了逐步的構建一個復雜系統的可能。在這種結構下，高層次的組件直接依賴于低層次的組件去實現一些任務。這種對于低層次組件的依賴限制了高層次組件被重用的可行性。

依賴反轉原則的目的是把高層次組件從對低層次組件的依賴中解耦出來，這樣使得重用不同層級的組件實現變得可能。把高層組件和低層組件劃分到不同的包/庫，該方式也促進了這種解耦。由于低層組件是對高層組件接口的具體實現，因此低層組件包的編譯是依賴于高層組件的，這顛倒了傳統的依賴關系。眾多的設計模式，比如插件、服務定位器或者依賴反轉，則被用來在運行時把指定的低層組件實現提供給高層組件。

具體而言，依賴反轉原則規定：

• 高層次的模塊不應該依賴于低層次的模塊，兩者都應該依賴于抽象接口。

• 抽象接口不應該依賴于具體實現。而具體實現則應該依賴于抽象接口。

舉個栗子，如果我們有一個從網站讀取元數據的程序，且主組件包含下載網站內容的組件和讀取元數據的組件。如果我們考慮依賴反轉原則，那么主組件只能依賴于某些抽象組件，其中某個抽象組件只能獲取比特數據、另一個只能從比特流中讀取元數據。主組件并不知道任何關于TCP/IP、HTTP或HTML等協議或格式的相關信息。

這一原則是比較復雜的，因為它似乎反轉了系統的依賴性關系。在實踐中，該原則意味著獨立的編排模塊必須確保使用了正確的抽象類型實現。例如在上面的例子中，元數據讀取模塊還是需要一些抽象類型的實現，即HTTP文件下載器和HTML元標簽讀取器。

推薦閱讀：

Python打牢基礎，從12個語法開始！

掃碼加入：（碎碎念、深深思）

總結

以上是生活随笔為你收集整理的GitHub最热！码代码不得不知的所有定律法则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。