新智元報導
來源：GitHub
編輯：金磊
【新智元導讀】作一個優秀的程式設計師，除了要會寫代碼，還要懂得職場的15大定律和7大原則。昨日，GitHub趨勢榜第一的項目便總結了這些定律和原則。總有一款適合你。
總有一款適合你。
作為程式設計師，你除了會敲代碼，還得知曉屬於你的定律。今日GitHub便有一個項目總結了與開發人員相關的15大定律和7大原則。
項目地址：
https://github.com/dwmkerr/hacker-laws
該項目目錄如下：
簡介定律
阿姆達爾定律(Amdahl's Law)布魯克定律(Brooks's Law)康威定律(Conway's Law)侯世達定律(Hofstadter's Law)阿瑪拉定律的「炒作周期」(The Hype Cycle & Amara's Law)海勒姆定律(Hyrum's Law)摩爾定律(Moore's Law)帕金森定律(Parkinson's Law)普特定律(Putt's Law)泰斯勒定律(複雜性守恆定律,Tesler's Law)抽象化漏洞定律(The Law of Leaky Abstractions)瑣碎定律(The Law of Triviality)Unix哲學(The Unix Philosophy)Spotify模型(The Spotify Model)Wadler定律(Wadler's Law)
原則
魯棒性原則(The Robustness Principle,Postel's Law)SOLID單一職責原則(The Single Responsibility Principle)開放封閉原則(The Open/Closed Principle)李氏替換原則(The Liskov Substitution Principle)接口分離原則(The Interface Segregation Principle)依賴倒置原則(The Dependency Inversion Principle)TODO
那麼接下來，我們就對這些定律和原則進行一一解讀。
開發人員需知的15大定律
阿姆達爾定律(Amdahl's Law)
維基百科中對此定律的解讀是：
阿姆達爾定律，一個計算機科學界的經驗法則，因吉恩·阿姆達爾而得名。它代表了處理器並行運算之後效率提升的能力。並行計算中的加速比是用並行前的執行速度和並行後的執行速度之比來表示的，它表示了在並行化之後的效率提升情況。阿姆達爾定律是固定負載（計算總量不變時）時的量化標準。
此處舉個例子來說明：如果一個程序由兩部分組成，一部分A(必須由一個處理器執行)和一部分B(可以並行執行)，那麼我們可以看到，向執行程序的系統添加多個處理器只能帶來有限的好處。它可以極大地提高B部分的速度，但是A部分的速度將保持不變。
下圖顯示了速度可能改進的一些示例：
可以看出，即使是一個50%可並行的程序，在超過10個處理單元的情況下也幾乎沒有什麼好處，而一個95%可並行的程序，在超過1000個處理單元的情況下，仍然可以顯著提高速度。
隨著摩爾定律(Moore’s Law)的放緩，以及單個處理器速度的加速放緩，並行化是提高性能的關鍵。圖形編程是一個很好的例子(使用現代基於著色器的計算，單個像素或片段可以並行呈現)，這就是為什麼現代顯卡通常有成千上萬的處理核心(gpu或著色器單元)。
布魯克定律(Brooks's Law)
維基百科中對此定律的解讀是：
將人力資源添加到一個後期軟體開發項目中會使它更晚。
這條定律表明，在許多情況下，試圖通過增加更多的人來加速已經晚了的項目，將使交付日期更晚。該定律楚地表明這是一種過度簡化，但一般的推理是，鑑於新資源的增加時間和通信開銷，在短期內的速度會降低。而且，許多任務可能不是可分的，即容易在更多資源之間分配，這意味著潛在的速度增長也更低。
交付工作中常見的一句話，「九個女人不能在一個月內生孩子」是與布魯克斯定律有關，特別是某些工作不可分割或平行的事實。
康威定律(Conway's Law)
維基百科中對此定律的解讀是：
這條法律表明，一個系統的技術邊界將反映組織的結構。
設計系統的組織受限於設計這些組織的通信結構的副本。
這條定律表明，一個系統的技術邊界將反映組織的結構。康威定律表明，如果一個組織是由許多小的、不相連的單元組成的，那麼它所生產的軟體將是如此。如果一個組織更多地圍繞功能或服務的「垂直領域」構建，軟體系統也會反映出這一點。
侯世達定律(Hofstadter's Law)
維基百科中對此定律的解讀是：
即使考慮了侯世達定律，它也總是比你想像的要花更長的時間。
當你在估計某件事需要多長時間的時候，你可能聽說過這個定律。在軟體開發中，我們往往不擅長準確地估計某個東西需要多長時間才能交付，這似乎是一個老生常談的事實。
阿瑪拉定律的「炒作周期」(The Hype Cycle & Amara's Law)
維基百科中對此定律的解讀是：
我們傾向於過高估計技術在短期內的影響，並低估長期效應。
Hype Cycle(炒作周期)是技術隨著時間的推移而產生的興奮和發展的直觀表現，最初由Gartner開發。最好用視覺效果來表現：
簡而言之，這一周期表明，人們通常對新技術及其潛在影響感到興奮。團隊經常快速地投入到這些技術中，有時會對結果感到失望。這可能是因為技術還不夠成熟，或者現實世界的應用還沒有完全實現。經過一段時間，技術的能力和使用它的實際機會都會增加，團隊最終會變得富有成效。羅伊阿馬拉(Roy Amara)的名言最簡潔地概括了這一點——「我們往往高估了一項技術的短期效果，而低估了長期效果。」
海勒姆定律(Hyrum's Law)
維基百科中對此定律的解讀是：
有足夠數量的API用戶，您在公約中承諾的並不重要：系統的所有可觀察行為都將取決於某人。
Hyrum定律指出，當一個API有足夠多的消費者時，這個API的所有行為(甚至那些沒有被定義為公約的一部分的行為)最終都會被某人所依賴。一個簡單的例子可能是非功能元素，比如API的響應時間。一個更微妙的例子可能是依賴於對錯誤消息應用正則表達式來確定API錯誤類型的消費者。
即使API的公約沒有聲明關於消息內容的任何內容，表明用戶應該使用相關的錯誤代碼，一些用戶也可能使用消息，更改消息實際上會破壞這些用戶的API。
摩爾定律(Moore's Law)
維基百科中對此定律的解讀是：
集成電路中的電晶體數量大約每兩年翻一番。
摩爾的預測經常被用來說明半導體和晶片技術進步的絕對速度。事實證明，從上世紀70年代到本世紀頭十年末，摩爾的預測是非常準確的。近年來，這一趨勢發生了輕微的變化，部分原因是對組件小型化程度的物理限制。然而，並行化的進步，以及半導體技術和量子計算領域潛在的革命性變化，可能意味著摩爾定律在未來幾十年仍將適用。
帕金森定律(Parkinson's Law)
維基百科中對此定律的解讀是：
工作量不斷增大，以填補滿足工作所需的截止時間。
在其最初的背景下，這個定律是基於對官僚機構的研究。它可能被"悲觀"地應用於軟體開發計劃，理論是團隊在截止日期之前效率低下，然後在截止日期前趕緊完成工作，從而使得實際截止日期變得有些隨意。
如果將這一定律與侯世達定律結合起來，就會得出一個更加悲觀的觀點——工作量將會增大，以填補完成它所需要的時間，而且仍然比預期的要長。
普特定律(Putt's Law)
維基百科中對此定律的解讀是：
技術由兩類人主導，一類人懂他們不並需要管理的事務，另一類人管理者他們不懂的事務。
普特定律往往遵循普特推理(Putt's Corollary)：
隨著時間的推移，每一個技術層次都會發展出一種能力倒置。
這些陳述表明，由於各種選擇標準和群體組織方式的趨勢，技術組織的工作層面將有一些技術人員，以及一些不了解複雜性和挑戰的管理角色的人員。
然而需要強調的是，此類定律是廣泛的概括，可能適用於某些類型的組織，而不適用於其他類型的組織。
泰斯勒定律(複雜性守恆定律,Tesler's Law)
維基百科中對此定律的解讀是：
這條定律表明，一個系統中有一定程度的複雜性是無法降低的。
系統中的某些複雜性是「無意的」。 這是由於結構不良、錯誤或者只是解決問題的糟糕建模造成的。 可以減少（或消除）這種「無意」的複雜性。然而，一些複雜性是「內在的」，這是所解決問題內在複雜性的結果。這種複雜性可以轉移，但不能消除。
這個定律中一個有趣的點，即使簡化了整個系統，內在的複雜性也沒有減少，而是轉移到了用戶身上，用戶必須以更複雜的方式行事。
抽象化漏洞定律(The Law of Leaky Abstractions)
維基百科中對此定律的解讀是：
在某種程度上，所有非平凡(non-trivial)抽象都是有漏洞的。
該定律指出，抽象化(通常用於計算以簡化複雜系統的工作)在某些情況下會「洩漏」底層系統的元素，這使得抽象化的行為方式出人意料。
加載文件並讀取其內容就是一個例子。文件系統API是較低層內核系統的抽象，內核系統本身是與更改磁碟片(或SSD的快閃記憶體)上的數據相關的物理進程的抽象。在大多數情況下，將文件處理為二進位數據流的抽象是可行的。然而，對於磁驅動器，順序讀取數據的速度將明顯快於隨機訪問(由於頁面錯誤的開銷增加)，但是對於SSD驅動器，不會出現這種開銷。處理這種情況需要了解底層細節(例如，資料庫索引文件的結構是為了減少隨機訪問的開銷)，開發人員可能需要了解抽象的「洩漏」實現細節。
當引入更多抽象時，上面的示例可能會變得更加複雜。Linux作業系統允許通過網絡訪問文件，但在本地表示為「普通」文件。如果存在網絡故障，這個抽象將會「洩漏」。如果開發人員將這些文件視為「正常」文件，而沒有考慮到它們可能會受到網絡延遲和故障的影響，那麼解決方案就會有bug。
瑣碎定律(The Law of Triviality)
維基百科中對此定律的解讀是：
這一定律表明，團體將把更多的時間和精力放在瑣碎或表面現象上，而不是嚴肅和實質性的問題。
Unix哲學(The Unix Philosophy)
維基百科中對此定律的解讀是：
Unix哲學是軟體組件應該很小，並且專注於做好一件特定的事情。通過將小的、簡單的、定義良好的單元組合在一起，而不是使用大型的、複雜的、多用途的程序，可以更容易地構建系統。
像「微服務體系結構」這樣的現代實踐可以被看作是這條定律的一個應用，此處，服務是小的、集中的，並且只做一件特定的事情，允許由簡單的構建塊組成複雜的行為。
Spotify模型(The Spotify Model)
維基百科中對此定律的解讀是：
Spotify模型是團隊和組織結構的一種方法，已被「Spotify」推廣。在這個模型中，團隊是圍繞功能而不是技術來組織的。
Spotify模型還普及了部落、公會、分會等組織結構的其它組成部分。
Wadler定律(Wadler's Law)
維基百科中對此定律的解讀是：
在任何語言設計中，討論這個列表中某個特性所花費的總時間與它位置的冪成正比。0.語義1.語法2.詞彙語法3.注釋的詞彙語法
類似於「瑣碎定律」，Wadler定律指出，在設計一種語言時，與這些特徵的重要性相比，花在語言結構上的時間是不成比例的。