《The Clean Coder》Podcast 準備稿：承諾與寫程式的紀律
書名： 無瑕的程式碼番外篇 The Clean Coder（A Code of Conduct for Professional Programmers） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜The Clean Coder．承諾要用「我」開頭，寫程式要清醒 (2/5) 涵蓋範圍： 第3章 說 是 ＋ 第4章 寫程式
背景速覽
上一集講「敢說不」，這一集講硬幣的另一面——怎麼正確地說「是」，以及一旦答應之後，寫程式時該守的紀律。第3章把「承諾」這件事拆解到語言層次：什麼樣的措辭才算真正的承諾，什麼樣的措辭只是在逃避責任。第4章則是 Uncle Bob 對「寫程式當下的心理狀態」的觀察，裡面藏著本書最有名、也最反直覺的一條警告：別追求心流。
一句話重點
真正的承諾是一句以「我」開頭、壓上明確期限與具體成果的話——而既然答應了，寫程式時就要管理好自己的精神狀態：疲勞時別寫、別迷信心流、用 TDD 把除錯時間壓到接近零，並且只有通過自動化驗收測試才叫「做完」。
值得討論的重點
1. 承諾的語言：聽到 hope / wish / should / let’s 就要警覺
Uncle Bob 把「承諾」拆到語言層次，這是這章最實用的部分。他列出一串「逃避責任的紅旗詞」：「我們應該做完（should/need）」「我希望明天能好（hope/wish）」「讓我們把這搞定（let’s）」——這些話的共同問題是沒有人真正負責：need/should 暗示期待但沒指定負責人；hope/wish 把結果交給運氣、等於放棄控制權；let’s 表面團結，實則稀釋個人承擔。真正的承諾長這樣：「我（I）將在〔某時間點〕之前，完成〔某具體成果〕。」 核心是那個「我」——你親自為結果負責，並壓上明確 deadline。
2. 不能承諾時，就承諾你「控制得了的行動」
很多時候我們不敢承諾，是因為有不可控因素——要等別人交付、需求還不清楚、或根本確定做不到。Uncle Bob 給的解法很漂亮：把承諾轉化到你控制得了的行動上。依賴第三方？那就「我無法承諾他們何時交付，但我承諾明天中午前聯繫他們，並每天追蹤到有回應為止」。需求不清楚？承諾先做一個「探勘（Spike）」釐清達標條件，把不確定性轉成已知。確定做不到？那就盡早通知——這本身就是一種風險控管，讓對方有時間調整，而不是等到最後一刻才引爆。
3. 疲勞時絕不寫程式，而且——別追求心流
第4章 Uncle Bob 主張嚴格管理自己的精神狀態。第一條好懂：疲勞、心煩、分心時寫出來的多半是垃圾，最後得花更多時間補，所以該停下來休息，別硬撐。第二條很反直覺：別刻意追求心流（flow）。多數工程師把那種忘我、時間飛逝的狀態當聖杯，但 Uncle Bob 警告：心流容易造成「管窺效應（tunnel vision）」——你過度專注局部，丟失了系統大局觀。他甚至建議寫程式時盡量別聽音樂（音樂誘發心流又吃掉一部分腦力），並推薦用結對程式設計主動打破單人沉迷，強迫大腦切換視角。
4. 製造 bug 的人不專業，TDD 讓除錯時間趨近於零
Uncle Bob 在這章把話講得很重：「花大量時間除錯，不是專業表現」「製造 bug 的開發者並不專業」。他的解方是全面採用 TDD——當測試覆蓋率夠高，你的除錯時間應該趨近於零。這是他把 TDD 從「一種測試手法」抬升成「專業義務」的鋪墊（下一集會展開）。同時他提醒：寫程式是馬拉松不是短跑，要保留體力；而且很多最好的解法是在離鍵盤的時候冒出來的——洗澡、開車、通勤時，讓大腦的背景程序去跑。
5. 「完成」的定義：通過自動化驗收測試，而且絕不交付一次爛貨
什麼叫寫完？Uncle Bob 說不是「我覺得寫好了」，而是通過業務和測試人員一起定義的自動化驗收測試。更關鍵的一條紀律：絕不交付失敗的成果，哪怕一次都不行——因為只要你允許低品質交付一次，標準就會永久性地往下掉。這條和上一集「QA 找到 bug 該羞愧」是同一個精神：品質沒有「這次例外」。
注意事項
⚠️ 「別追求心流」是本書最容易被誤讀、也最有爭議的一條。 Uncle Bob 反的是「為了那種爽感而刻意沉浸、結果丟了大局」，不是反對專注本身——深度工作的價值（見 Cal Newport《Deep Work》）是有大量證據支持的。比較公允的說法是：心流是好工具但不是目的，你要的是「帶著大局觀的專注」，而不是「鑽進牛角尖出不來」。別讓聽眾聽成「專注是壞事」，那就矯枉過正了。
⚠️ 「製造 bug 就不專業」「除錯時間應趨近於零」這種絕對化語氣要平衡。 現實裡再強的工程師都會寫出 bug，複雜系統的 bug 也不可能全靠 TDD 攔掉（並行、整合、需求理解錯誤都會漏）。把這條當成「方向」——盡量前移品質、別把除錯當常態——是健康的；當成「字面 KPI」就會變成自我苛責甚至造假。Uncle Bob 講話一向偏激進，這是他的風格，聽的人要自己折扣。
專家補充
💡 「承諾要用『我』開頭」這條，和現代責任工程文化裡的「DRI（Directly Responsible Individual，直接負責人）」是同一個底層邏輯——Apple 內部、後來很多公司沿用：每件事都要有一個、且只有一個名字掛在上面。模糊的「我們應該」之所以危險，正是因為「人人有責 ＝ 沒人負責」。Uncle Bob 從語言切入，DRI 從制度切入，殊途同歸。
💡 「最好的解法在離鍵盤時冒出來」這件事有神經科學背景——這叫孵化效應（incubation effect），大腦的預設模式網路（default mode network）在你「不專心」時反而會做遠距聯想、整合資訊。所以卡關時去散步、洗澡不是偷懶，是在動用另一套認知系統。這條可以替工程師「光明正大地離開螢幕」正名。
💡 「絕不交付一次爛貨，否則標準永久下滑」這條，對應到一個有名的軟體現象——「破窗理論」在程式碼裡的版本（《The Pragmatic Programmer》提出）：一扇沒修的破窗會招來更多破窗。一段被容忍的爛 code、一次被默許的爛交付，會迅速把整個團隊的品質基準線往下拉。品質是會傳染的，往好往壞都是。
討論問題
🎙️ 開場鉤子：「回想你上次說『我們應該可以在週五前搞定』——這句話裡，到底是『誰』承諾了『什麼』？如果你答不出來，那它根本不是承諾，只是一句讓大家安心的廢話。」
🎙️ 自問自答：「Uncle Bob 說別追求心流——可是我最爽、覺得最有產出的時候不就是心流嗎？」可以誠實拆：他反的是「丟了大局的沉迷」，不是專注本身；真正的問題是你出心流之後，有沒有退一步看整體？這題沒有標準答案，正好拿來跟聽眾一起想。
🎙️ 帶走的一題：「這禮拜挑一個任務，練習把承諾講成完整句：『我會在〔哪天幾點〕之前，交出〔什麼具體東西〕。』如果你發現自己講不出這句、只能講『我盡量』——那正是一個訊號：你其實還沒準備好承諾，該回頭釐清的是需求或依賴，不是嘴上先答應。」
更大範圍關聯
- 承上啟下：第3章「說是」是第2章「說不」的另一半——說不是設界線，說是是給承諾，兩章合起來才是 Uncle Bob 完整的「承諾倫理」。第4章「寫程式」則把焦點從「對外溝通」轉回「對內自律」，並為下一集的 TDD 鋪好梯子（除錯該趨近於零、完成＝通過驗收測試，都是 TDD 的引子）。
- 與職涯經典對話：「承諾的語言」這個切角，和《The Pragmatic Programmer》的「別找藉口，提供選項（Provide options, don’t make lame excuses）」是同一脈——專業溝通的核心是「我負責、我給可行方案」，而不是「我希望、我盡量」。
- 與深度工作對話：第4章對「心流」的保留，正好和 Cal Newport《Deep Work》站在一個有趣的對立面——Newport 把深度專注奉為圭臬，Uncle Bob 卻提醒專注的陰暗面（失去大局）。這組張力是這集最值得讓聽眾自己評斷的地方。
- 領域定位：用 [軟體工程領域切分藍圖] 看，這兩章橫跨「溝通協作」（承諾、預期管理）與「個人工作法」（精神狀態、節奏管理）兩支，都屬於「程式碼之外的專業能力」——是讓 senior 之所以是 senior 的那層東西。
錄製建議
- 建議時長：約 20 分鐘。配比：說是／承諾約 10 分（「紅旗詞」清單很好演，一條一條對照聽眾自己的口頭禪），寫程式約 10 分（心流爭議是亮點，留時間好好辯）。
- 討論策略：第3章用「紅旗詞」當互動點——現場唸 hope / wish / should / let’s，讓聽眾邊聽邊抓自己昨天講過哪幾句，代入感最強。第4章主打「別追求心流」這個反直覺鉤子，但記得做平衡（見注意事項），別讓它變成反智的「專注有害論」。兩章的共同主線是「紀律」：對外承諾的紀律、對內精神狀態的紀律，可以用這條線把整集縫起來。
- 結尾自然接續：「答應了、也清醒地寫了，那要怎麼確保真的沒寫壞？下一集進入 Uncle Bob 心中專業的試金石——TDD 與練習。」