為什麼「快速迭代」是高槓桿活動#
Facebook 早期內部牆上有句口號：「Move fast and break things.」 作者葉禮華（Edmond Lau）在 Quora 工作時，團隊每天透過持續部署（Continuous Deployment）發版 40-50 次，平均每次變更只需 7 分鐘就能跑完成千上萬個測試並上線給數百萬使用者。
Mark Zuckerberg 在 Facebook 上市公開信中寫道：「快速移動讓我們能建立更多事物、學得更快。 公司之所以變慢，往往是因為比起『因移動過慢而錯失機會』，他們更害怕『犯錯』。」
迭代速度之所以是高槓桿活動，源於：
- 更多嘗試、更多學習：每次迭代都讓你更了解什麼可行、什麼不可行
- 小批次降低風險：問題容易定位，回滾容易，事故影響面小
- 學習的複利：因為學習本身有複利，越早提升迭代速度，後續成長越快
持續部署的本質#
持續部署不是「犧牲品質換取速度」，而是「用小批次降低風險」。 財富管理新創 Wealthfront 在 SEC 嚴格監管下管理數十億美元資產，仍能每天部署 30 次以上。其前 CTO Pascal-Louis Perez 強調：「持續部署的主要優勢是降低風險——它讓團隊聚焦在小批變更上，問題出現時能快速定位。」
實現持續部署的工程投資：
- 自動化版本與打包工具
- 跨機器平行執行的單元／整合測試框架
- 金絲雀（Canary）伺服器驗證
- 健全的儀表板與告警
- 簡單可靠的回滾機制
- 用功能開關（Feature Flag）控制大功能的開放範圍
投資省時工具（Time-saving Tools）#
Facebook 前基礎設施工程總監 Bobby Johnson：「我發現幾乎所有成功的人都會寫很多工具…… 一個人遇到問題時，第一件事是寫工具，那就是未來成功的高度指標。」
Twitter 前平台工程副總 Raffi Krikorian 常提醒團隊：「如果你必須手動做某件事兩次以上，就在第三次寫工具。」
書中以兩位工程師對比： Mark 直接埋頭做功能，Sarah 先花兩週優化工作流（增量編譯、自動 reload、自動化腳本）讓開發速度加快 33%。八週後，兩人完成的功能量相當，但此後 Sarah 每週都比 Mark 多產出 33%——而且這只是低估。
為什麼工具的回報通常被低估#
- 更快的工具會被用得更頻繁：搭乘飛機讓人們頻繁飛舊金山與紐約之間，火車時代不可能
- 更快的工具會解鎖新的工作流：編譯從 20 分鐘降到秒級時，工程師不再「批次抓錯」，而是依賴編譯器即時提示
- 工具的效益會隨採用人數放大：替團隊 1,000 名工程師每次建構各省一分鐘，每週累計可省下將近一個人年的工時
工具的價值是可量化的：若團隊每週花 3 小時人工處理伺服器當機，而你投入 12 小時寫自動重啟工具，一個月內就回本。 用實際數據說服同事與主管，會替你累積去探索更大膽想法的「自由額度」。
落實建議#
- 善用主流 IDE：Visual Studio、IntelliJ 等具備廣大社群支援，獲得豐富的套件與除錯能力
- 自動化重複腳本：啟動本地端服務、建置、部署都應一鍵完成
- 降低工具切換成本：如果你的工具比較好，但同事不肯換，主動把它整合進現有工作流（如把命令列建置工具掛進既有 IDE）
縮短除錯與驗證的迴圈#
Instagram 共同創辦人兼 CTO Mike Krieger：「Effective 工程師對於建立『緊密回饋迴圈』有種偏執的本能。 如果他們在處理 iOS App 拍照流程的 Bug，就會直覺地花 20 分鐘把流程綁好，讓自己一按按鈕就能直接跳到那個狀態。」
工程師花在除錯與驗證的時間比想像中多。願意投資縮短這段迴圈的人，效率拉得最大。
三個常見場景#
- iOS 邀請流程的 Bug：別每次都點三層介面，寫個啟動參數讓 App 一打開就跳到出錯狀態
- 分析報表的 Bug：透過 URL 參數直接帶入過濾條件與日期區間，省下每次點擊與配置時間
- A/B 測試變體驗證：寫個內部小工具能直接設定 Cookie，而不必每次硬編碼條件並重新編譯
「最小化可重現」思維延伸到工作流#
我們熟悉 Bug 報告要附「最小可重現範例」，這個思維也應該延伸到日常開發迴圈本身。 當你發現自己重複在做同樣的動作，停下來思考能否把這個迴圈縮短，往往能省下大量時間。
精通你的程式環境#
我們一輩子會花無數小時在文字編輯器、IDE、瀏覽器、版本控制與命令列上。 這些日常工具熟練度的差異，累積下來就是一個工作週、甚至更多時間。
書中描述一位 Google 工程師習慣用 Finder 點開資料夾找檔案：每次 12 秒，一天 60 次切換，就是 12 分鐘。 學會編輯器快捷鍵後降到 2 秒，一天省 10 分鐘——一年就是整整一個工作週。
七項基本功#
- 熟練你的編輯器或 IDE：不論是 Emacs、Vim、Sublime、IntelliJ，把搜尋取代、檔案跳轉、自動補全練到反射動作
- 精通至少一個高生產力的腳本語言：C/C++/Java 通常比 Python/Ruby 多 2-3 倍程式碼量，把腳本語言當瑞士刀
- 熟悉 UNIX Shell 命令：grep、sort、uniq、wc、awk、sed、xargs、find 串起來能在數秒內完成原本要幾分鐘的事
- 以鍵盤優先於滑鼠：減少手部移動，降低脈絡切換成本
- 自動化手動流程：作者的個人原則是「同一手動操作做超過三次就考慮自動化」
- 善用互動式直譯器（REPL）：Python、Ruby、JavaScript 都有，能即時驗證表達式
- 讓單元測試容易跑、跑得快：只跑受影響的測試子集，整合進編輯器快捷鍵
別忽略「非工程」的瓶頸#
Donald Knuth 名言：「Premature optimization is the root of all evil（過早的最佳化是萬惡之源）。」 若你的瓶頸是每週審查會議，再快的部署系統也救不了。
最佳化迭代速度的本質就是辨識最大瓶頸並消除它。瓶頸不一定是技術。
三類常見人為／流程瓶頸#
- 相依性過高：依賴他人的設計稿、後端 API、產品需求遲遲未到
- 解法：透過例行 Stand-up、會議筆記、書面追蹤確認進度。專案多半因「溝通不足」失敗，極少因「過度溝通」失敗
- 必要時自己接手對方的工作，雖然多花學習成本，但能讓功能更早出貨
- 決策者遲遲未拍板：上司審查或關鍵主管尚未認可
- 解法：及早爭取早期回饋（Office Hours、原型展示、初步數據），別等做到最後才送審
- 如果沒辦法直接找決策者，透過長期共事的 PM、設計師了解他們在意什麼
- 發布前的審查流程拖延：QA、效能、資安審核排程很晚才安排
- 解法：把審查當作 Launch Checklist 的一部分，提早通知與排程
- 在小公司，瓶頸通常可以直接打掉；在大公司則往往只能繞過
重點摘要（Key Takeaways）#
- 快速迭代帶來快速學習：因怕犯錯而放慢腳步，反而錯失機會
- 投資工具：編譯、部署、開發週期的時間節省會隨次數放大
- 優化除錯流程：別低估驗證成本，主動縮短迴圈
- 精通核心工具：日復一日的小節省，累積成長期競爭力
- 整體視角看迭代：注意人為與組織流程瓶頸，並儘可能改善影響圈內的部分
