《Clean Craftsmanship》Podcast 準備稿：標準．Bob Martin 當你的新 CTO

書名： 整潔的軟體工藝 Clean Craftsmanship（Disciplines, Standards, and Ethics） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜Clean Craftsmanship．你必須學會說「不」 (7/9) 涵蓋範圍： Part II The Standards（生產力、品質、勇氣）

背景速覽

Part I 講「怎麼做」（紀律），Part II 翻頁講「做到什麼程度」（標準）。Uncle Bob 用一個很妙的框架：想像 Bob Martin 是你的新任 CTO，他要告訴你他對你的期望。妙就妙在這些期望會引發兩種互相矛盾的反應——管理者/使用者覺得「這不是理所當然嗎」，程式設計師卻覺得「這根本不可能、瘋了」。Uncle Bob 說：這道落差，正是軟體產業最主要的失敗。這集涵蓋三大標準：生產力、品質、勇氣。

一句話重點

標準是「劃在沙上、不可跨越的底線」——而軟體業的核心病灶是「期望落差」：老闆覺得「軟體本來就該能用、能改、沒 bug」天經地義，工程師卻覺得這些要求極端到不可能；Uncle Bob 的整個 Part II 就是在說：這些期望其實做得到，差的是紀律與勇氣，不是現實限制。

值得討論的重點

1. 生產力：絕不交付垃圾，且永遠保持「可發布」

CTO 對生產力的四個期望：

• 絕不交付垃圾：bug、未測的功能、爛函式、不必要的耦合、GUI 裡的 SQL……都是垃圾。工程師可以做權衡（trade-off），但權衡要有「好理由 + 好的緩解計畫」——例如 CSS 難自動測，緩解計畫是手動跨瀏覽器測、定畫面規格，而且開發者自己測，不丟給 QA。
• 低成本的可適應性：software 的字根是 soft，存在的全部理由就是好改。把軟體寫到難改，就背叛了它的本質。當客戶提合理變更，成本該與範圍成正比——「一個抵制客戶合理變更的架構，是背叛軟體意義的架構」。
• 隨時準備好：每個 sprint 結束時軟體在技術上已可發布（商業上發不發是另一回事）。Uncle Bob 講了個故事：某團隊學了 XP 後每週燒一張 CD 放實驗室，業務要 demo 直接拿最上面那張走——這就是「隨時準備好」的程度。
• 穩定的生產力：生產力不該是一條向下的曲線。下滑的惡性循環是「程式碼糾結 → 恐懼 → 不敢清理 → 更糟 → 加人（新人也被恐懼感染）→ 要求重寫」。

2. 品質：QA 應該什麼都找不到

這章最有衝擊力。CTO 對品質的期望從「持續改善」「無畏的專業能力（Fearless Competence）」一路推到一個極致標準：QA 應該什麼都找不到。背後的診斷很尖銳——公司為什麼要養一整個部門檢查程式設計師的工作？「因為程式設計師沒做好自己的工作。」更毒的是「QA 病（The QA Disease）」：如果用「找到多少 bug」評價 QA，QA 就會把 bug 當好事，開發者也樂得「反正 QA 會抓」——於是開發者和 QA 之間形成一個心照不宣的「bug 經濟」。Uncle Bob 的解法：QA 不該在流程末端找 bug，QA 該在流程開頭定義測試規格；bug 是程式設計師該擋掉的，不是 QA 該撿的。配套是測試自動化（能自動化的都自動化，手動只留給美學、探索性測試、易用性這些需要人類判斷的場景）。

3. 勇氣：你必須學會說「不」

勇氣這章最實用、最有戲。五個期望裡，「You Must Say NO」是核心：

• 程式設計師能說的最重要的話之一就是「不」。「我們是工程師，工作是找到通往『是』的路——但有時『是』就是不可能，而我們是唯一能判斷的人。」
• 場景：老闆要你週五交，你評估後做不到。你必須說「不行，但我可以下週二」，而且要頂得住情緒對抗（吼叫、對質是某些管理者的工具）。
• 最該警惕的陷阱是「你能不能至少試試看？」——聽起來很合理，其實不合理，因為你已經在盡力了，沒有新做法能把「不」變「是」，所以說「我試試」就是說謊。

其他三個：互相補位（確保有人能替你補位是你的責任）、誠實估算（最誠實的估算是「我不知道」，所以用機率分布而非單一日期）、持續積極學習 + Mentoring（每年學一門不同風格的語言；教學是學得最好的方式）。

注意事項

⚠️ 整個 Part II 是 Uncle Bob 最理想主義、也最容易引戰的部分，務必標清「應然 vs 實然」。「QA 應該什麼都找不到」「絕不交付垃圾」是高張力的應然主張，不是業界現狀的描述。批評者會說：複雜系統的 bug 在數學上不可能歸零（測試無法窮舉，呼應 EP3 不確定性原理），把目標訂成「零缺陷」可能製造不健康的壓力與防衛文化。公允的講法是——把它當成「北極星目標」（朝它走、每次 QA 找到 bug 就回去修流程），而不是「沒做到就是失職」的審判。

⚠️ 「QA 該什麼都找不到」很容易被誤聽成「不需要 QA」。Uncle Bob 的意思恰恰相反——QA 很重要，但該前移到流程開頭定義規格，而不是末端當人肉防火牆。現代 DevOps/QE（Quality Engineering）的趨勢其實和他一致（shift-left testing），這點可以替他補一句現代背書。

⚠️ 「你必須說不」這條金句在真實職場有權力結構的現實。Uncle Bob 預設你有足夠的專業資本與心理安全去頂老闆——資淺工程師、或在高壓/不健康的組織裡，硬頂的代價可能很高。講的時候要誠實：這是一個值得追求的專業姿態，但怎麼說「不」、在什麼籌碼下說，需要智慧。Uncle Bob 的另一本《Clean Coder》對「怎麼專業地說不」有更細的劇本，可以指路。

專家補充

💡 「期望落差」這個開場框架，其實點破了軟體業很多衝突的根源。老闆說「不就改個按鈕嗎」與工程師說「這牽動整個架構」之間的鴻溝，往往不是誰對誰錯，而是雙方對『軟體的可塑性』有完全不同的心智模型。Uncle Bob 的主張是：這道鴻溝該由工程師用紀律去填平——讓「改個按鈕真的就是改個按鈕」，而不是反過來要求老闆理解技術債。這個責任歸屬的判斷很關鍵，也很 Uncle Bob。

💡 「bug 經濟」是這章最犀利的觀察，值得多停留。它揭示了一個組織設計的反面教材：當你用『找到 bug 數』獎勵 QA、用『準時交付』獎勵開發者，你就用激勵機制親手養出了一條 bug 生產線。這是 Goodhart’s Law（指標一旦變成目標就不再是好指標）在軟體團隊裡的活例子——延伸到任何 KPI 設計都成立。

💡 「誠實估算 = 機率分布而非單一日期」這點，是整本書少數「給管理者也很受用」的工具。把估算講成「5% 機率這週五、50% 下週五、95% 再下週五」，比賭一個日期誠實得多，也能保護工程師不被一個拍腦袋的日期綁架。下下一集（Teamwork）會用 PERT 把這套講得更量化，這裡先埋伏筆。

討論問題

🎙️ 開場鉤子：「假設 Bob Martin 明天當你的 CTO，第一天就丟給你一張期望清單。你老闆看了會說『這不是基本的嗎』，你看了會說『這根本不可能』——這道落差，就是今天的主題。」

🎙️ 自問自答：「為什麼公司要花錢養一個 QA 部門檢查我們的 code？」——Uncle Bob 的答案讓人不舒服但誠實：因為我們沒做好自己的工作。

🎙️ 拋給聽眾：「你上一次對老闆說『不』是什麼時候？還是你都用『我試試看』來逃避？Uncle Bob 說：說『我試試』而沒有新計畫，就是說謊。」

🎙️ 帶走的一題：「下次給時程估算時，別給一個日期。給三個：樂觀、正常、最壞。練習把『不確定性』誠實地講出來。」

更大範圍關聯

• 「怎麼專業地說不」的延伸：Uncle Bob《The Clean Coder》(2011) 整本書就在講「程式設計師的專業行為」，其中說不、估算、面對壓力講得比本章細——本集是濃縮版，那本是完整劇本。
• 零缺陷的思想史：「絕不交付垃圾」可上溯到製造業的 Toyota Production System 與 Deming 的品質哲學（品質內建於流程，而非末端檢驗）——Uncle Bob 的「QA 前移」本質上是 Deming「stop inspecting quality in」的軟體版。
• 同系列接點：本章的「結構優先」「無畏能力」直接承接 EP5 的重構/簡單設計；「說不」「誠實估算」「互相補位」則是下兩集 Part III 倫理誓言的預演（Promise 7、8）。
• 領域定位：用 [軟體工程領域切分藍圖] 看，Part II 站在「職業素養/工程文化」這塊，是從「技術紀律」邁向「職業倫理」的橋樑——也是和《The Clean Coder》重疊度最高的一部。

錄製建議

• 建議時長：約 22-25 分鐘（三章合併，但主題集中）。配比：CTO 框架與期望落差 4 分、生產力（絕不交付垃圾/隨時可發布）6 分、品質（QA 病/QA 找不到）7 分、勇氣（說不/誠實估算/學習）6 分。
• 討論策略：用「Bob Martin 當你 CTO」這個第二人稱框架貫穿全集，代入感最強。「bug 經濟」和「你必須說不」是兩個天生的記憶點，務必講透、講出戲劇性。整集要不斷拉「應然 vs 實然」這條平衡線——Uncle Bob 在這部最容易被當成不食人間煙火，誠實呈現理想與現實的張力，正是節目「帶腦讀經典」的價值。結尾預告：下集進入全書最高層、也最有野心的 Part III——倫理與「程式設計師的誓言」。