用聽的閱讀《Google的軟體工程之道》(Software Engineering at Google)

想讀這本書《Google的軟體工程之道》(Software Engineering at Google) 的原因是當工程師最重要的是有良好的技術品味，再來是能融會貫通手上的技能、端出完整的解法，最後才是追技術；而這本書能帶給我們的就是這個良好的觀念與方向，讓我們在面對技術選擇時能夠有一個清晰的思路與原則來做出決策。

也由於換工作之後通勤時間增加，因此把這本書的內容經由 NotebookLM 轉成語音檔當成 Podcast 來聽，讓自己在通勤時也能持續學習。

以下是我所製作的 Podcast 檔案連結，並附上每一章節的重點摘要，歡迎大家一起來聽聽看 (♡˙︶˙♡)

Part1 主題

• Ch1 何謂軟體工程？ - 寫程式與軟體工程的本質差異
  • 程式設計是產生程式碼的單純直接行為，而軟體工程則是「隨著時間推移的程式設計」，兩者的本質差異在於軟體工程必須額外考量時間（長期的程式碼維護）、規模（團隊協作與系統擴張），以及在面對這些變化時所需做出的複雜權衡與決策。

Part2 文化

• Ch2 如何做好團隊合作 - 打破天才神話的_Google_協作心法
  • 你我必須認知到偉大的軟體專案皆是團隊集體努力而非個人英雄主義的成果，因此工程師必須克服害怕犯錯的不安全感並放下自負，將「謙遜（Humility）、尊重（Respect）與信任（Trust）」這三大社交支柱作為一切互動的基石，以打造互助健康的高效團隊文化。
• Ch3 知識共享 - Google 打破知識孤島的祕訣
  • 建立允許犯錯與提問的心理安全環境，並透過導師制度、廣泛的社群交流、建立規範的文件訊息源，以及標準化的程式碼審查（可讀性）流程，培養且實質獎勵積極共享知識的團隊文化。
• Ch4 公平工程 - 為什麼 Google 演算法有偏見
  • Google 演算法之所以會產生偏見，主要是因為工程師本身帶有無意識的偏見，加上工程團隊缺乏多元代表性，導致在設計演算法與蒐集訓練資料時，未能充分涵蓋並反映真實世界中所有族群的特徵與需求。
• Ch5 如何領導團隊 - 抵抗管理的衝動
  • 管理者應避免微管理，而是「服務型領導」- 為團隊服務、清除障礙、維護團隊的技術與社交健康。
• Ch6 領導力的發展 - 讓團隊沒你也行
• 作為領導者，你的任務並非永遠親力親為，而是要透過充分授權與培養人才，打造出一個即使沒有你在場也能自主解決問題的自驅型組織，藉此釋放自己的精力去應對全新的挑戰。
• Ch7 衡量工程效率 - Google 如何衡量工程效率
  • Google 衡量工程效率的核心在於建立專門的生產力研究團隊，運用 GSM（目標、訊號、指標）框架與涵蓋五大權衡維度的 QUANTS（質量、關注度、複雜度、速度、滿意度）原則，並結合定量與定性資料來選擇具備可操作性的指標，從而做出能實際推動團隊改進的資料驅動決策。

Part3 過程

• Ch8 格式指南與規則 - Google 用自動化終結程式碼爭議
  • Google 透過全面採用自動化的樣式檢查與格式化工具來強制執行一致的程式碼規範，藉此徹底消除了工程師在程式碼審查時對排版細節的無謂爭論與時間浪費。
• Ch9 程式碼審查 - 程式碼是 Google 最大的負擔
  • 程式碼本質上是一種需要被持續維護的長期負債，因此 Google 強烈不鼓勵工程師從零開始編寫新程式碼，而是提倡在開發前審慎評估新功能的必要性並盡可能重用現有的程式碼與基礎設施，以避免製造重複且昂貴的維護成本。
• Ch10 文件 - 像寫程式一樣寫文件
  • 「像寫程式一樣寫文件」的核心理念是將文件視同原始碼進行管理，將其納入版本控制系統、指定明確的所有者，並透過既有的程式碼審查與錯誤追蹤等開發工作流程來進行維護與更新。
• Ch11 測試概述 - 廁所裡的軟體測試課
  • 「廁所測試」是一項透過在洗手間隔間張貼簡短且具可操作性的單頁測試技巧傳單，進而成功提高全公司對自動化測試重視。
• Ch12 單元測試 - 測試行為不測細節
  • 「測試行為，不測細節（方法）」原則提倡透過公開 API 來驗證系統在特定狀態下的預期行為與最終結果（測試「做什麼」），而非針對內部方法或底層實作的互動細節進行測試（不測「怎麼做」），藉此確保測試的清晰度並大幅降低測試的脆弱性。
• Ch13 測試替身 - 為什麼建議少用 Mock
  • 建議少用 Mock（模擬）是因為過度使用會將程式碼的內部實作細節洩露到測試中，導致測試變得脆弱、難以閱讀且有效性降低，這不僅無法確保系統實際運作的正確性，還會產生與真實實作不同步的重複程式碼，進而嚴重阻礙未來的程式碼重構。
• Ch14 較大型的測試 - 預防全球大當機的大型測試
  • 大型測試目的在補足單元測試的侷限性，透過在接近真實的複雜環境中執行部署設定測試、災難恢復演練（DiRT）與混沌工程，來驗證系統的整體行為與容錯能力，藉此預防因設定錯誤或突發狀況所引發的全球性大當機。
• Ch15 棄用 - 程式碼是負債而非資產
  • 程式碼本身並不能帶來價值，反而會隨著時間推移產生持續的維護與營運成本，因此程式碼本質上是一種「負債」，而真正的「資產」是其所提供的功能，這要求我們盡可能用最精簡的程式碼來實現最大化功能，並積極廢棄不再需要的過時系統以控制成本。

Part4 工具

• Ch16 版本控制和分支管理 - 萬人協作的單一版本規則
  • 為了讓萬人團隊高效協作，Google 強烈提倡「基於主幹的開發」與強制執行的「單一版本規則」，藉由消除開發者對依賴版本的選擇權，並避免使用長期開發的分支，來徹底解決鑽石依賴與合併衝突等問題，進而極大地提升大型組織的開發與擴充套件效率。
• Ch17 程式碼搜尋 - 如何秒搜 1.5TB 程式碼
  • 為了應對龐大程式碼庫的擴充套件挑戰，Google 專門開發了「程式碼搜尋（Code Search）」網頁工具，透過高度最佳化的稀疏 n-gram 反向索引與雲端後端技術，讓工程師能在極低延遲下瞬間檢索、瀏覽並理解高達 1.5TB 的程式碼，從而極大地提升了開發效率。
• Ch18 建構系統與建構哲學 - 用限制自由換取極致效率
  • Google 發現「限制工程師的權力與靈活性反而能提升生產力」，因此放棄了允許任意自定義指令碼的任務型建立系統，轉而採用規範嚴格的「基於構件（Artifact-Based）」建立系統，藉由限縮個人選擇並將控制權交還給自動化系統，成功換取了建立過程的極致速度、正確性與大規模分散式擴充套件能力。
• Ch19 Google 的程式碼審查工具 - 把信任寫進按鈕的 Critique
  • Google 的程式碼審查工具 Critique 將「信任」視為核心的設計基礎，透過極簡的介面、靈活的批准機制（如 LGTM）以及與其他開發工具的緊密整合，將程式碼審查從拖慢進度的關卡轉變為賦能開發者的利器，在保證程式碼品質的同時大幅提升了團隊的大規模協作效率。
• Ch20 靜態分析 - 靜態分析背後的心理學
  • Google 靜態分析成功的核心在於高度重視「開發者的幸福感」，透過維持極低的誤報率來建立使用者信任，將其無縫融入程式碼審查等日常核心工作流程中，並鼓勵工程師共同貢獻檢查規則，從而讓靜態分析成為賦能開發者的得力助手，而非擾人的阻礙。
• Ch21 依賴關係管理 - 軟體工程的依賴地獄生存戰
  • 軟體工程中的依賴管理旨在處理隨時間演進且不受控的外部程式碼網絡，為了解決傳統語意版本控制（SemVer）的侷限與鑽石依賴衝突，Google 提倡盡可能將其轉化為原始碼控制問題，並實施「單一版本規則」與仰賴持續測試的「Live at Head（始終使用最新版本）」策略，以確保系統在規模化下的長期維護性與穩定性。
• Ch22 大規模變更 - 大規模程式碼自動翻修術
  • 「大規模變更（LSC）」是為了解決龐大程式碼庫無法一次性進行單一原子送出的擴充套件難題，透過高度自動化的專屬工具（如 Rosie）將全域性的程式碼重構與升級拆分為數千個可獨立測試、審查與送出的小型變更，讓少數基礎設施工程師就能高效推動影響全公司的程式碼翻修，以確保系統長期的彈性、一致性與可維護性。
• Ch23 持續整合 - 每天四十億次測試的防護網
  • 持續整合核心在於建立快速的反應回饋，並仰賴 TAP（測試自動化平台）每天執行超過四十億次測試，透過自動化建立與分層的持續測試機制在極早期攔截錯誤，為大規模軟體開發構築出兼顧速度與品質的堅實防護網。
• Ch24 持續交付 - 軟體開發越快越安全
  • 持續交付的核心理念在於「越快越安全」，提倡透過儘早、頻繁且小批次地發布軟體，來大幅降低每次發布的風險與時間成本，並藉由快速獲取真實使用者的反饋進行資料驅動決策，最終實現產品質量與開發速度的雙贏。
• Ch25 運算即服務 - 如何把伺服器當牛群管理
  • 將伺服器當作「牛群」而非「寵物」來管理，意味著企業需全面採用容器化與自動化排程技術來取代人工維護，並要求工程師將軟體架構設計為能容忍節點隨機失效、狀態可分離的分散式系統，從而實現系統的自動修復與運算資源的大規模高效利用。

Part5 總結

• 後記 - 對抗時間與偏見的軟體工程
  • 軟體工程的核心不僅在於建立可持續擴充套件且能應對時間變化的龐大程式碼庫，更要求工程師肩負起對抗偏見的社會責任，確保技術設計具備包容性、公平性與可訪問性，從而打造出真正造福所有使用者的創新。