作一個優(yōu)秀的程序員，除了要會寫代碼，還要懂得職場的15大定律和7大原則。昨日，GitHub趨勢榜第一的項目便總結(jié)了這些定律和原則。總有一款適合你。

總有一款適合你。

作為程序員，你除了會敲代碼，還得知曉屬于你的定律。今日GitHub便有一個項目總結(jié)了與開發(fā)人員相關(guān)的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

那么接下來，我們就對這些定律和原則進行一一解讀。

開發(fā)人員需知的15大定律

阿姆達爾定律(Amdahl's Law)

維基百科中對此定律的解讀是：

阿姆達爾定律，一個計算機科學界的經(jīng)驗法則，因吉恩·阿姆達爾而得名。它代表了處理器并行運算之后效率提升的能力。并行計算中的加速比是用并行前的執(zhí)行速度和并行后的執(zhí)行速度之比來表示的，它表示了在并行化之后的效率提升情況。阿姆達爾定律是固定負載（計算總量不變時）時的量化標準。

此處舉個例子來說明：如果一個程序由兩部分組成，一部分A(必須由一個處理器執(zhí)行)和一部分B(可以并行執(zhí)行)，那么我們可以看到，向執(zhí)行程序的系統(tǒng)添加多個處理器只能帶來有限的好處。它可以極大地提高B部分的速度，但是A部分的速度將保持不變。

下圖顯示了速度可能改進的一些示例：

可以看出，即使是一個50%可并行的程序，在超過10個處理單元的情況下也幾乎沒有什么好處，而一個95%可并行的程序，在超過1000個處理單元的情況下，仍然可以顯著提高速度。

隨著摩爾定律(Moore’s Law)的放緩，以及單個處理器速度的加速放緩，并行化是提高性能的關(guān)鍵。圖形編程是一個很好的例子(使用現(xiàn)代基于著色器的計算，單個像素或片段可以并行呈現(xiàn))，這就是為什么現(xiàn)代顯卡通常有成千上萬的處理核心(gpu或著色器單元)。

布魯克定律(Brooks's Law)

維基百科中對此定律的解讀是：

將人力資源添加到一個后期軟件開發(fā)項目中會使它更晚。

這條定律表明，在許多情況下，試圖通過增加更多的人來加速已經(jīng)晚了的項目，將使交付日期更晚。該定律楚地表明這是一種過度簡化，但一般的推理是，鑒于新資源的增加時間和通信開銷，在短期內(nèi)的速度會降低。而且，許多任務可能不是可分的，即容易在更多資源之間分配，這意味著潛在的速度增長也更低。

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

康威定律(Conway's Law)

維基百科中對此定律的解讀是：

這條法律表明，一個系統(tǒng)的技術(shù)邊界將反映組織的結(jié)構(gòu)。

設計系統(tǒng)的組織受限于設計這些組織的通信結(jié)構(gòu)的副本。

這條定律表明，一個系統(tǒng)的技術(shù)邊界將反映組織的結(jié)構(gòu)?？低杀砻鳎绻粋€組織是由許多小的、不相連的單元組成的，那么它所生產(chǎn)的軟件將是如此。如果一個組織更多地圍繞功能或服務的“垂直領(lǐng)域”構(gòu)建，軟件系統(tǒng)也會反映出這一點。

侯世達定律(Hofstadter's Law)

維基百科中對此定律的解讀是：

即使考慮了侯世達定律，它也總是比你想象的要花更長的時間。

當你在估計某件事需要多長時間的時候，你可能聽說過這個定律。在軟件開發(fā)中，我們往往不擅長準確地估計某個東西需要多長時間才能交付，這似乎是一個老生常談的事實。

阿瑪拉定律的“炒作周期”(The Hype Cycle & Amara's Law)

維基百科中對此定律的解讀是：

我們傾向于過高估計技術(shù)在短期內(nèi)的影響，并低估長期效應。

Hype Cycle(炒作周期)是技術(shù)隨著時間的推移而產(chǎn)生的興奮和發(fā)展的直觀表現(xiàn)，最初由Gartner開發(fā)。最好用視覺效果來表現(xiàn)：

簡而言之，這一周期表明，人們通常對新技術(shù)及其潛在影響感到興奮。團隊經(jīng)常快速地投入到這些技術(shù)中，有時會對結(jié)果感到失望。這可能是因為技術(shù)還不夠成熟，或者現(xiàn)實世界的應用還沒有完全實現(xiàn)。經(jīng)過一段時間，技術(shù)的能力和使用它的實際機會都會增加，團隊最終會變得富有成效。羅伊?阿馬拉(Roy Amara)的名言最簡潔地概括了這一點——“我們往往高估了一項技術(shù)的短期效果，而低估了長期效果?！?/p>

海勒姆定律(Hyrum's Law)

維基百科中對此定律的解讀是：

有足夠數(shù)量的API用戶，您在公約中承諾的并不重要：系統(tǒng)的所有可觀察行為都將取決于某人。

Hyrum定律指出，當一個API有足夠多的消費者時，這個API的所有行為(甚至那些沒有被定義為公約的一部分的行為)最終都會被某人所依賴。一個簡單的例子可能是非功能元素，比如API的響應時間。一個更微妙的例子可能是依賴于對錯誤消息應用正則表達式來確定API錯誤類型的消費者。

即使API的公約沒有聲明關(guān)于消息內(nèi)容的任何內(nèi)容，表明用戶應該使用相關(guān)的錯誤代碼，一些用戶也可能使用消息，更改消息實際上會破壞這些用戶的API。

摩爾定律(Moore's Law)

維基百科中對此定律的解讀是：

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

摩爾的預測經(jīng)常被用來說明半導體和芯片技術(shù)進步的絕對速度。事實證明，從上世紀70年代到本世紀頭十年末，摩爾的預測是非常準確的。近年來，這一趨勢發(fā)生了輕微的變化，部分原因是對組件小型化程度的物理限制。然而，并行化的進步，以及半導體技術(shù)和量子計算領(lǐng)域潛在的革命性變化，可能意味著摩爾定律在未來幾十年仍將適用。

帕金森定律(Parkinson's Law)

維基百科中對此定律的解讀是：

工作量不斷增大，以填補滿足工作所需的截止時間。

在其最初的背景下，這個定律是基于對官僚機構(gòu)的研究。它可能被"悲觀"地應用于軟件開發(fā)計劃，理論是團隊在截止日期之前效率低下，然后在截止日期前趕緊完成工作，從而使得實際截止日期變得有些隨意。

如果將這一定律與侯世達定律結(jié)合起來，就會得出一個更加悲觀的觀點——工作量將會增大，以填補完成它所需要的時間，而且仍然比預期的要長。

普特定律(Putt's Law)

維基百科中對此定律的解讀是：

技術(shù)由兩類人主導，一類人懂他們不并需要管理的事務，另一類人管理者他們不懂的事務。

普特定律往往遵循普特推理(Putt's Corollary)：

隨著時間的推移，每一個技術(shù)層次都會發(fā)展出一種能力倒置。

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

然而需要強調(diào)的是，此類定律是廣泛的概括，可能適用于某些類型的組織，而不適用于其他類型的組織。

泰斯勒定律(復雜性守恒定律,Tesler's Law)

維基百科中對此定律的解讀是：

這條定律表明，一個系統(tǒng)中有一定程度的復雜性是無法降低的。

系統(tǒng)中的某些復雜性是“無意的”。 這是由于結(jié)構(gòu)不良、錯誤或者只是解決問題的糟糕建模造成的。 可以減少（或消除）這種“無意”的復雜性。然而，一些復雜性是“內(nèi)在的”，這是所解決問題內(nèi)在復雜性的結(jié)果。這種復雜性可以轉(zhuǎn)移，但不能消除。

這個定律中一個有趣的點，即使簡化了整個系統(tǒng)，內(nèi)在的復雜性也沒有減少，而是轉(zhuǎn)移到了用戶身上，用戶必須以更復雜的方式行事。

抽象化漏洞定律(The Law of Leaky Abstractions)

維基百科中對此定律的解讀是：

在某種程度上，所有非平凡(non-trivial)抽象都是有漏洞的。

該定律指出，抽象化(通常用于計算以簡化復雜系統(tǒng)的工作)在某些情況下會“泄漏”底層系統(tǒng)的元素，這使得抽象化的行為方式出人意料。

加載文件并讀取其內(nèi)容就是一個例子。文件系統(tǒng)API是較低層內(nèi)核系統(tǒng)的抽象，內(nèi)核系統(tǒng)本身是與更改磁盤片(或SSD的閃存)上的數(shù)據(jù)相關(guān)的物理進程的抽象。在大多數(shù)情況下，將文件處理為二進制數(shù)據(jù)流的抽象是可行的。然而，對于磁驅(qū)動器，順序讀取數(shù)據(jù)的速度將明顯快于隨機訪問(由于頁面錯誤的開銷增加)，但是對于SSD驅(qū)動器，不會出現(xiàn)這種開銷。處理這種情況需要了解底層細節(jié)(例如，數(shù)據(jù)庫索引文件的結(jié)構(gòu)是為了減少隨機訪問的開銷)，開發(fā)人員可能需要了解抽象的“泄漏”實現(xiàn)細節(jié)。

當引入更多抽象時，上面的示例可能會變得更加復雜。Linux操作系統(tǒng)允許通過網(wǎng)絡訪問文件，但在本地表示為“普通”文件。如果存在網(wǎng)絡故障，這個抽象將會“泄漏”。如果開發(fā)人員將這些文件視為“正?！蔽募鴽]有考慮到它們可能會受到網(wǎng)絡延遲和故障的影響，那么解決方案就會有bug。

瑣碎定律(The Law of Triviality)

維基百科中對此定律的解讀是：

這一定律表明，團體將把更多的時間和精力放在瑣碎或表面現(xiàn)象上，而不是嚴肅和實質(zhì)性的問題。

Unix哲學(The Unix Philosophy)

維基百科中對此定律的解讀是：

Unix哲學是軟件組件應該很小，并且專注于做好一件特定的事情。通過將小的、簡單的、定義良好的單元組合在一起，而不是使用大型的、復雜的、多用途的程序，可以更容易地構(gòu)建系統(tǒng)。

像“微服務體系結(jié)構(gòu)”這樣的現(xiàn)代實踐可以被看作是這條定律的一個應用，此處，服務是小的、集中的，并且只做一件特定的事情，允許由簡單的構(gòu)建塊組成復雜的行為。

Spotify模型(The Spotify Model)

維基百科中對此定律的解讀是：

Spotify模型是團隊和組織結(jié)構(gòu)的一種方法，已被“Spotify”推廣。在這個模型中，團隊是圍繞功能而不是技術(shù)來組織的。

Spotify模型還普及了部落、公會、分會等組織結(jié)構(gòu)的其它組成部分。

Wadler定律(Wadler's Law)

維基百科中對此定律的解讀是：

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

0.語義

1.語法

2.詞匯語法

3.注釋的詞匯語法

類似于“瑣碎定律”，Wadler定律指出，在設計一種語言時，與這些特征的重要性相比，花在語言結(jié)構(gòu)上的時間是不成比例的。