[[265686]]

從小到大，我們學(xué)過很多定律，見過許多法則。近日，猿妹在GitHub上找到一個專屬程序員的定律&法則合集項目。

自從我知道這個項目后，已經(jīng)連續(xù)一周霸榜GitHub Trending前三，如今已經(jīng)在GitHub上獲得4337 個Star，231 個Fork(GitHub地址：https://github.com/dwmkerr/hacker-laws)

這個倉庫包含對一些定律、原則以及模式的解釋，共有15大定律和7大原則，但不提倡其中任何一個。 它們的應(yīng)用始終存在著爭論，并且很大程度上取決于你正在做什么。

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

阿姆達爾定律是一個顯示計算任務(wù)潛在加速能力的公式。這種能力可以通過增加系統(tǒng)資源來實現(xiàn)，通常用于并行計算中。它可以預(yù)測增加處理器數(shù)量的實際好處，然而增加處理器數(shù)量會受到程序并行性的限制。

舉例說明：如果程序由兩部分組成，部分 A 必須由單個處理器執(zhí)行，部分 B 可以并行運行。那么向執(zhí)行程序的系統(tǒng)添加多個處理器只能獲得有限的好處。它可以極大地提升部分 B 的運行速度，但部分 A 的運行速度將保持不變。

下圖展示了運行速度的潛能：

可以看出，50% 并行化的程序僅僅受益于 10 個處理單元，而 95% 并行化的程序可以通過超過一千個處理單元顯著提升速度。

隨著摩爾定律減慢，單個處理器的速度增加緩慢，并行化是提高性能的關(guān)鍵。圖形編程是一個極好的例子，現(xiàn)代著色器可以并行渲染單個像素或片段。這也是為什么現(xiàn)代顯卡通常具有數(shù)千個處理核心(GPU 或著色器單元)的原因。

布魯克斯法則 (Brooks's Law)

軟件開發(fā)后期，添加人力只會使項目開發(fā)得更慢。

這個定律表明，在許多情況下，試圖通過增加人力來加速延期項目的交付，將會使項目交付得更晚。布魯克斯也明白，這是一種過度簡化。但一般的推理是，新資源的增加時間和通信開銷，會使開發(fā)速度減慢。而且，許多任務(wù)是不可分的，比如更多的資源容易分配，這也意味著潛在的速度增加也更低。

諺語九個女人不能在一個月內(nèi)生一個孩子 與布魯克斯法則同出一轍，特別是某些不可分割或者并行的工作。

康威定律 (Conway's Law)

系統(tǒng)的技術(shù)邊界受制于組織的結(jié)構(gòu)。改進組織時，通常會提到它。康威定律表明，如果一個組織被分散成許多小而無聯(lián)系的單元，那么它開發(fā)的軟件也是小而分散的。如果一個組織更多地垂直建立在特性或其服務(wù)周圍，那么軟件系統(tǒng)也會反映這一點。

侯世達定律 (Hofstadter's Law)

即使考慮到侯世達定律，它也總是比你預(yù)期的要長。

在估計需要多長時間開發(fā)時，你可能會聽到此定律。軟件開發(fā)似乎不言而喻，我們往往不能準確地估計需要多長時間才能完成。

技術(shù)成熟度曲線 (The Hype Cycle & Amara's Law)

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

技術(shù)成熟度曲線是高德納咨詢公司對技術(shù)最初興起和發(fā)展的視覺展現(xiàn)。一圖頂千言：

簡而言之，這個周期表明，新技術(shù)及其潛在影響通常會引發(fā)一陣浪潮。團隊快速使用這些新技術(shù)，有時會對結(jié)果感到失望。這可能是因為該技術(shù)還不夠成熟，或者現(xiàn)實應(yīng)用還沒有完全實現(xiàn)。經(jīng)過一段時間后，技術(shù)的能力提高了，使用它的實際機會會增加，最終團隊也可以提高工作效率。羅伊·阿馬拉簡潔地總結(jié)了這一點：我們傾向于高估技術(shù)短期內(nèi)的影響，并低估長期效應(yīng)。

查看其它的定律和法則，可以到GitHub詳情頁查看，如果你自我感覺英文水平不行還有中文版哦，附上中文地址：https://github.com/nusr/hacker-laws-zh