[[265686]]

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

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

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

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

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

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

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

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

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

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

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

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

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

康威定律 (Conway's Law)

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

侯世達定律 (Hofstadter's Law)

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

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

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

我們傾向于過高估計技術在短期內的影響，并低估長期效應。

技術成熟度曲線是高德納咨詢公司對技術最初興起和發展的視覺展現。一圖頂千言：

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

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