1. 編譯速度的演進#

1982 年，作者拿到第一台 IBM PC，面對的是漫長的編譯等待。軟體開發的核心循環——Edit-Compile-Test——其速度直接影響開發者的生產力。早期的工具如 Turbo Pascal 大幅縮短了編譯時間，證明了快速回饋循環的價值。

開發生產力的關鍵不在於打字速度，而在於 Edit-Compile-Test 循環的總耗時。任何能縮短此循環的改善，都會帶來倍增的效益。

2. 每日構建的核心概念#

每日構建（Daily Build）改善的是更大層級的循環：Report-Fix-Retest loop。其三大特徵：

• 自動化：不依賴人工記憶或手動操作，由腳本自動完成
• 每日執行：固定排程，確保持續整合的節奏
• 完整構建：從原始碼開始，涵蓋所有模組與元件

3. 每日構建的好處#

3.1 快速取得修復版本#

當 bug 被修復後，QA 團隊或使用者能在隔天就拿到包含修復的版本，不需要等待漫長的釋出週期。

3.2 開發者信心#

每次成功的構建都是一次驗證：程式碼至少能正確編譯並通過基本測試。這給予團隊持續前進的信心。

3.3 行銷與展示用途#

行銷團隊隨時可以取得最新的穩定版本進行展示或客戶演示，不需要向開發團隊臨時要求「能跑的版本」。

3.4 歷史存檔與除錯#

保留每日構建的產物，當出現難以追蹤的 bug 時，可以透過二分搜尋法（binary search）找出是哪一天引入的問題。

4. 如何建立每日構建流程#

4.1 基礎建設#

• 部署一台高速的構建伺服器，專門用於編譯與打包
• 自動化版本控制的 checkout 流程
• 自動化編譯、連結、打包的完整流程

4.2 文件化#

將整個構建流程文件化，確保任何團隊成員都能理解並維護構建腳本。避免構建流程成為單一成員的「黑箱知識」。

4.3 構建腳本的維護#

• 腳本應涵蓋所有必要步驟，不依賴任何手動操作
• 從乾淨的環境開始構建，確保可重現性

5. 最佳實踐#

• 腳本涵蓋一切：從 checkout 到最終安裝包，所有步驟都包含在構建腳本中
• 立即修復構建錯誤：構建失敗是最高優先級的問題，必須即刻處理
• 通知機制：構建失敗時自動通知整個團隊，讓責任歸屬清晰
• 維護可見的構建日誌：讓所有人都能看到構建狀態與歷史記錄
• 排程考量：若團隊跨時區，需安排多個構建時段，確保所有成員都能在工作日開始時取得最新版本

構建失敗後的第一件事不是追究責任，而是立即修復。讓「構建永遠是綠的」成為團隊文化。

6. 品質控制與成本效益#

修 bug 不應該是「發現就修」的反射動作，而應基於成本效益分析。

作者用花生醬果醬工廠的比喻說明：假設生產線上偶爾有瓶蓋沒蓋好的問題，修復這個問題的成本是否值得？答案取決於：

• 問題發生的頻率
• 每次問題造成的損失
• 修復的工程成本
• 修復後可能帶來的連帶風險

品質控制的本質是經濟決策：只有當修復的價值大於修復的成本時，才值得投入資源去修。