綜合自：
從小到大，我們學過很多定律，見過許多法則。近日，猿妹在github上找到乙個專屬程式設計師的定律＆法則合集專案。
這個倉庫包含對一些定律、原則以及模式的解釋，共有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)
我們傾向於過高估計技術在短期內的影響，並低估長期效應。
技術成熟度曲線是高德納諮詢公司對技術最初興起和發展的視覺展現。一圖頂千言：
簡而言之，這個週期表明，新技術及其潛在影響通常會引發一陣浪潮。團隊快速使用這些新技術，有時會對結果感到失望。這可能是因為該技術還不夠成熟，或者現實應用還沒有完全實現。經過一段時間後，技術的能力提高了，使用它的實際機會會增加，最終團隊也可以提高工作效率。羅伊·阿馬拉簡潔地總結了這一點：我們傾向於高估技術短期內的影響，並低估長期效應。
程式設計師應該懂的道理 2
十 九 監督小池定理 越是沉醉，就越是抓住眼前的東西不放。提出者 日本管理學家小池敬 點評 自我陶醉不易清醒，自以為是不喜批評。赫勒法則 當人們知道自己的工作成績有人檢查的時候會加倍努力。提出者 英國管理學家h 赫勒 點評 只有在相互信任的情況下，監督才會成為動力。二 十 控制 橫山法則 最有效並持...
2023年度十大高薪崗位出爐，程式設計師霸榜
12月15日，職場社交平台脈脈發布了 2020人才吸引力報告 報告基於對1.1億職場使用者和社交招聘大資料分析後發現，有57 的人變得比前幾年更加焦慮，而產生焦慮的 按佔比依次是工作 積蓄 疫情 生活 身體 情感和其他。2020年，打工人 成為職場熱詞，而這一自嘲用語，既是排遣焦慮，也是表達對職場流...
程式設計師必須懂的架構入門課
程式設計師，真有必要了解架構嗎？在解答這個疑惑之前，我們先來看一則故事 旅行者路過某個工地，建築工人們都在忙碌。出於好奇，旅行者問第乙個人在幹什麼，那人頭也沒抬地回答道 我在搬磚。旅行者問第二個人在幹什麼，這個匆匆抬起頭認真地說 我在砌牆。旅行者問第三個人在幹什麼，那個人臉上充滿了光彩，很自豪地說 ...