▲?點擊上方“老于的筆記”關注公眾號

回復1，免費獲取B端運營地圖

正文來了

精選了7個原則和15個定律，互聯網人公認的牛出天際！

產品經理照著做策劃，保證懟開發、懟測試、懟老板，不在話下。

原則：

• 魯棒性原則（The Robustness Principle (Postel's Law)

• 單一責任原則（The Single Responsibility Principle）

• 開放/封閉原則（The Open/Closed Principle）

• 接口隔離原則（The Interface Segregation Principle）

• 依賴反轉原則（The Dependency Inversion Principle）

• ……

定律：

• 炒作周期 & 阿瑪拉定律（The Hype Cycle & Amara's Law）

• 帕金森定律（Parkinson's Law）

• 復雜性守恒定律（泰斯勒定律）（The Law of Conservation of Complexity (Tesler's Law)）

• 抽象漏洞定律（The Law of Leaky Abstractions）

• 瑣碎定律（The Law of Triviality）

• Spotify模型（The Spotify Model）

  ……

  No 1

  7個牛X的原則

01

魯棒性原則

保守自己的所做所為，但是要接受別人的自由。

通常應用于服務器應用程序開發中，該原則指出你發送給其他人的內容應盡可能小且符合要求，但如果可以處理，則應該瞄準允許不符合要求的輸入。該原則的目標是構建穩健的系統，因為如果仍然可以理解意圖，它們可以處理形成不良的輸入。但是，接受格式錯誤的輸入可能存在安全隱患，特別是如果此類輸入的處理未經過充分測試。

02

SOLID

這是一個縮寫，指的是：

• S：單一責任原則

• O：開放/封閉原則

• L：Liskov替代原則

• I：接口隔離原理

• D：依賴性倒置原則

這些是面向對象編程的關鍵原則。諸如此類的設計原則應該能夠幫助開發人員構建更易于維護的系統。

03

單一責任原則

每個模塊或類只應承擔一項責任。

這是第一個'SOLID'原則。這個原則表明模塊或類只應該做一件事，并且只有一件事。更實際的是，這意味著對程序功能的單個小的更改應該只需要更改一個組件。例如，更改密碼驗證復雜性的方式應該只需要更改程序的一部分。

從理論上講，這應該使代碼更健壯，更容易修改。知道正在改變的組件只有一個責任，這意味著測試該改變應該更容易。使用前面的示例，更改密碼復雜性組件應該只能影響與密碼復雜性相關的功能。對于具有許多職責的組件的變更影響可能要困難得多。

04

開放/封閉原則

實體應開放以進行擴展并關閉以進行修改。

這是第二個'SOLID'原則。這個原則規定實體（可以是類，模塊，函數等）應該能夠擴展它們的行為，但是它們的現有行為不應該被修改。

作為一個假設的例子，想象一個能夠將Markdown文檔轉換為HTML的模塊。如果可以擴展模塊以處理新建議的降價功能，而無需修改模塊內部，則可以進行擴展。如果消費者無法修改模塊以便處理現有的Markdown功能，那么它將被關閉以進行修改。

這個原則與面向對象編程特別相關，我們可以設計對象以便于擴展，但是可以避免設計可能以意想不到的方式改變其現有行為的對象。

0505

利斯科夫替代原則

應該可以在不破壞系統的情況下用子類型替換類型。

這是第三個'SOLID'原則。該原則指出，如果組件依賴于類型，那么它應該能夠使用該類型的子類型，而不會導致系統失敗或必須知道該子類型的詳細信息。

舉個例子，假設我們有一個方法，它從表示文件的結構中讀取XML文檔。如果該方法使用基類型'file'，則應該能夠在函數中使用從'file'派生的任何內容。如果'file'支持反向搜索，并且xml解析器使用該函數，但是當嘗試反向搜索時派生類型'network file'失敗，則'network file'將違反該原則。

該原則與面向對象的編程特別相關，其中必須仔細建模類型層次結構以避免混淆系統的用戶。

06接口隔離原則

接口隔離原則

不應該強迫任何客戶端依賴它不使用的方法。

這是第四個'SOLID'原則。該原則指出組件的使用者不應該依賴于它實際上不使用的那個組件的功能。

作為一個例子，假設我們有一個方法從表示文件的結構中讀取XML文檔。它只需要讀取文件中的字節，向前移動或向后移動。如果由于文件結構的不相關功能發生更改（例如更新用于表示文件安全性的權限模型）而需要更新此方法，則原則已失效。文件最好實現“可搜索”接口，并讓XML讀者使用它。

該原理與面向對象的編程特別相關，其中使用接口，層次結構和抽象類型來最小化不同組件之間的耦合。Duck typing是一種通過消除顯式接口來強制執行此原則的方法。

07

依賴反轉原則

高級模塊不應該依賴于低級實現。

這是第五個'SOLID'原則。該原則指出，更高級別的協調組件不應該知道其依賴關系的細節。

例如，假設我們有一個程序從網站讀取元數據。我們假設主要組件必須知道下載網頁內容的組件，然后是可以讀取元數據的組件。如果我們考慮依賴性反轉，主要組件將僅依賴于可以獲取字節數據的抽象組件，然后是一個能夠從字節流中讀取元數據的抽象組件。主要組件不了解TCP / IP，HTTP，HTML等。

這個原則很復雜，因為它似乎可以“反轉”系統的預期依賴性（因此名稱）。實際上，它還意味著單獨的編排組件必須確保使用抽象類型的正確實現（例如，在前面的示例中，某些東西仍必須為元數據讀取器組件提供HTTP文件下載器和HTML元標記讀取器）。然后，它涉及諸如控制反轉和依賴注入之類的模式。

No 2

15個牛X的定律

01

?阿姆達爾定律

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

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

可以看出，即使是50％可并行化的程序也將受益于10個處理單元，其中95％可并行化的程序仍然可以通過超過一千個處理單元實現顯著的速度提升。

隨著摩爾定律的減慢，以及單個處理器速度的加速減慢，并行化是提高性能的關鍵。圖形編程是一個很好的例子 - 使用基于Shader的現代計算，可以并行渲染單個像素或片段 - 這就是為什么現代圖形卡通常具有數千個處理核心（GPU或Shader單元）。

02

布魯克斯定律

將人力資源添加到后期軟件開發項目中會使其更晚。

該定律表明，在許多情況下，試圖通過增加更多人來加速已經遲到的項目的交付，將使交付甚至更晚。布魯克斯清楚地表明這是一種過度簡化，一般想法是，由于時間和通信開銷的增加，在短期內效率會降低。而且，許多任務可能不是可分的，即容易在更多資源之間分配，這意味著潛在的效率也會更低。

交付中的常見短語“九個女人不能在一個月內生孩子”與布魯克斯定律有關，特別是某些工作不可分割或平行的事實。

03

康威定律

該定律提出系統的技術邊界將反映組織的結構。在查看組織改進時，通常會提到它，Conway定律表明，如果一個組織由許多小的、斷開連接的單元組成，那么它就是生成的軟件。

如果一個組織更多地建立在圍繞特征或服務的“垂直”周圍，那么軟件系統也會反映這一點。

04

霍夫施塔特定律

即使考慮到霍夫施塔特定律，它也總是比你預期的要長。

在查看需要多長時間的估計時，你可能會聽到此定律。

在軟件開發中似乎不言而喻，我們往往不能很好準確地估計需要多長時間才能完成。

0205

炒作周期 & 阿瑪拉定律

我們傾向于高估短期內技術的影響，并低估長期效應。（Roy Amara）

炒作周期是Gartner最初提出的技術興奮和發展的直觀表現。它可以很好用圖來顯示：

簡而言之，這個周期表明，新技術及其潛在影響通常會引發一陣興奮。團隊經?？焖龠M入這些技術，有時會發現自己對結果感到失望。

這可能是因為該技術還不夠成熟，或者現實應用還沒有完全實現。經過一段時間后，技術的能力提高，使用它的實際機會增加，團隊最終可以提高工作效率。

羅伊·阿馬拉（Roy Amara）簡潔地總結了這一點 ——“我們傾向于高估短期內技術的影響，并低估長期效應”。

06

Hyrum定律

如果某個API有足夠數量的用戶，那么你在合同中承諾的并不重要：因為系統的所有可觀察行為都將取決于某個人。（Hyrum Wright）

Hyrum定律指出，當你擁有足夠數量的API消費者時，API的所有行為（即使那些未被定義為公共合同的行為）最終都會被某人依賴。

一個簡單的例子可能是非功能元素，例如API的響應時間。一個更微妙的例子可能是依賴于將正則表達式應用于錯誤消息以確定API的錯誤類型的消費者。

即使API的公共合同沒有說明消息的內容，指示用戶應該使用相關的錯誤代碼，一些用戶可能會使用該消息，并且更改消息實質上會破壞這些用戶的API。

07

摩爾定律

集成電路中的晶體管數量大約每兩年翻一番。

通常用于說明半導體和芯片技術提高的絕對速度，從20世紀70年代到21世紀后期，摩爾的預測已被證明是高度準確的。

近年來，這種趨勢略有變化，部分原因是對組件小型化程度的物理限制。然而，并行化的進步，以及半導體技術和量子計算的潛在革命性變化可能意味著摩爾定律可能在未來幾十年內繼續保持正確。

08

帕金森定律

工作范圍擴大可以填補完成時間。

在其原始背景下，該定律是基于對官僚機構的研究。它可能會悲觀地應用于軟件開發計劃，理論是團隊在截止日期之前效率低下，然后在截止日期前趕緊完成工作，從而使實際截止日期有些隨意。

如果該定律與霍夫施塔特定律相結合，則會達到更加悲觀的觀點——工作將擴大以填補完成所需的時間，但仍需要比預期更長的時間。

09

Putt's Law

技術由兩類人主導，一類是理解他們不管理東西的人，另一類是管理他們不理解東西的人。

這些陳述表明，由于各種選擇標準和群體組織方式的趨勢，技術組織的工作層面將有一些技術人員，以及一些不了解他們正在管理的工作復雜性和挑戰的管理角色的人員。

這可能是由于彼得原則或迪爾伯特定律等現象造成的。但是，應該強調的是，諸如此類的法律是一種廣泛的概括，可能適用于某些類型的組織，而不適用于其他組織。

10

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

該定律規定系統中存在一定程度的復雜性不能減少。系統中的某些復雜性是“無意的”。這是由于結構不良、錯誤或者只是解決問題的糟糕建模造成的，可以減少（或消除）無意的復雜性。

然而，由于要解決的問題固有的復雜性，某些復雜性是“內在的”， 這種復雜性可以移動，但不能消除。

該定律的一個有趣的地方是即使通過簡化整個系統，內在的復雜性也不會降低，它會轉移給用戶，用戶必須以更復雜的方式行事。

11

抽象漏洞定律

在某種程度上，所有非常規的抽象都是漏洞。（Joel Spolsky）

該定律指出，通常用于計算以簡化復雜系統而處理的抽象將在某些情況下在底層系統中“泄漏”元素，這使得抽象表現為意外的方式。

一個例子可能是加載文件并讀取其內容。

文件系統API是較低級別內核系統的抽象，它們本身是與磁盤（或SSD的閃存）上的數據更改相關的物理過程的抽象。

在大多數情況下，處理文件（如二進制數據流）的抽象將起作用。但是，對于磁驅動器，順序讀取數據將明顯快于隨機訪問（由于頁面錯誤的開銷增加），但對于SSD驅動器，此開銷不會出現。

需要理解基礎細節以處理這種情況（例如，數據庫索引文件的結構可以減少隨機訪問的開銷），開發人員可能需要注意的抽象“泄漏”實現細節。

當引入更多抽象時，上面的示例會變得更復雜。Linux操作系統允許通過網絡訪問文件，但在本地表示為“普通”文件。

如果存在網絡故障，這種抽象將“泄漏”。如果開發人員將這些文件視為“正常”文件，而不考慮它們可能會受到網絡延遲和故障的影響，那么解決方案就會出錯。

描述該法律的文章表明，過度依賴抽象，加上對基礎過程的不了解，實際上使得在某些情況下處理手頭的問題變得更加復雜。

12

瑣碎定律

該定律表明，群體將給予更多的時間和注意力來處理瑣碎或美容問題，而不是嚴肅而實質性的問題。

使用的常見虛構的例子是委員會批準核電站的計劃，他們大部分時間都在討論自行車棚的結構，而不是電廠本身更為重要的設計。如果沒有高度的主題專業知識或準備，很難就有關非常大的復雜主題的討論提供寶貴的意見。但是，人們希望看到人們提供寶貴的意見。

因此，傾向于將過多的時間集中在小細節上，這可以很容易地推理，但不一定特別重要。上面的虛構例子導致使用“自行車脫落”這個詞作為浪費時間在瑣碎細節上的表達。

13

Unix哲學

Unix哲學認為軟件組件應該很小，并專注于做一件特定的事情。通過將小型、簡單、定義良好的單元組合在一起，而不是使用大型、復雜的多用途程序，這樣可以更輕松地構建系統。

像“微服務架構”這樣的現代實踐可以被認為是這種定律的應用，其中服務很小，集中并做一件特定的事情，允許復雜的行為由簡單的構建塊組成。

14

Spotify模型

Spotify模型是團隊和組織結構的一種方法，已被“Spotify”推廣。在此模型中，團隊圍繞功能而非技術進行組織。

Spotify模型還普及了段落、行會、章節的概念，這些是其組織結構的其他組成部分。

15

沃德勒定律

在任何語言設計中，在任何語言設計中，花在討論列表中某個特性上的總時間都與位置的二次冪成正比。

??? 語義
??? 句法
??? 詞法語法
??? 評論的詞法語法

簡而言之，對于語義上花費的每一個小時，將在評論的語法上花費8小時。

類似于“瑣碎定律”，沃德勒定律指出，在設計一種語言時，與這些特征的重要性相比，與花在語言結構上的時間是不成比例的。

··················END··················

我的新書內容不僅僅涵蓋了產品設計，還包括 B 端產品的商業模式、運營增長等內容。

第 1 章介紹了打造成功 B 端產品的注意事項和 B 端產品的 商業模式，

第 2 章梳理了 B 端產品需求調研、產品設計、產品研發、運營 增長的一些基本原則和共識，

第 3 章和第 4 章介紹了理解業務、滿足場景 和實現價值的方法，

第 5 章和第 6 章闡述了 B 端產品如何梳理業務架構，提升易用性，滿足個性化需求，

第 7 章到第 10 章分別介紹了完善客戶畫像、 內容營銷、活動營銷和線上渠道營銷相關的知識。

圖片來源于網絡

若好的建議和想法，歡迎在下方留言

因為公眾號平臺改變了推送規則，如果你還想如?？吹轿业奈恼?#xff0c;記得點一下在看和星標哦，同時也可以把干貨轉給有需要的小伙伴，期待我們不定期的相遇 ：）

總結

以上是生活随笔為你收集整理的地表最强22个互联网定律和原则：炒作周期、依赖反转原则、Spotify模型……的全部內容，希望文章能夠幫你解決所遇到的問題。

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