《The Pragmatic Programmer 務實的程式設計師》Podcast 準備稿：基本工具
書名： 務實的程式設計師 The Pragmatic Programmer（Your Journey to Mastery, 20th Anniversary Edition） 作者： David Thomas & Andrew Hunt 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜The Pragmatic Programmer．純文字、Shell、版控、除錯：工匠的傢伙 (4/11) 涵蓋範圍： 第3章 基本工具（Topic 16-22：純文字的威力、Shell 遊戲、功能強大的編輯器、版本控制、除錯、操縱文字、工程日誌）
背景速覽
第三章把鏡頭從哲學與方法轉到「工具」。作者用木工的比喻開場：每個工匠都從一組精選、耐用、合手的基本工具開始旅程。而程式設計師最常犯的錯，是只窩在單一 IDE 的舒適介面裡、從不離開。這章不是教你某個特定軟體，而是主張一組「不會過時的底層工具素養」——純文字、命令列、編輯器流暢度、版本控制、系統化除錯、文字處理語言、紙筆日誌。這些是「雙手的延伸」，磨利了就終身受用。
一句話重點
務實程式設計師的工具哲學是「投資在不會過時的底層素養」——把知識存成純文字、用 shell 和文字處理語言自動化、追求編輯器流暢度、對一切用版本控制、把除錯當成系統化的解題而非情緒事件——因為工具放大才能，工具越利、用得越熟，你越有生產力。
值得討論的重點
1. 純文字的威力：把知識存成能活過應用程式的格式
Tip 25「Keep Knowledge in Plain Text」。作者主張持久儲存知識的最佳格式是純文字。二進位格式的致命傷是「理解資料所需的脈絡，和資料本身是分開的」——沒有原始程式去解析，那堆 byte 毫無意義。純文字則是自我描述、獨立於建立它的應用程式。注意「純文字」不等於「非結構化」——HTML、JSON、YAML、HTTP/SMTP 都是純文字。它有三大好處：防過時（資料活得比任何應用程式久，且你只需部分格式知識就能解析，二進位通常要全懂才解得開）、槓桿效應（計算宇宙裡幾乎每個工具都能操作純文字——這正是 Unix「小而銳利、各做一件事」哲學能成立的基礎）、更易測試（合成測試資料、回歸測試輸出都能用簡單腳本處理）。在異質、長壽的環境裡，純文字是「最小公分母」。
2. Shell、編輯器、文字處理：把重複動作交給機器
三個 Topic 一條心——讓手上的操作自動化、流暢化。Shell 遊戲（Tip 26 Use the Power of Command Shells）：GUI 受限於設計者想到的操作，shell 讓你組合工具、把輸出接成管線，做出設計者沒預期的事。功能強大的編輯器（Tip 27 Achieve Editor Fluency）：追求編輯動作成為無意識反射——不必精通十種編輯器，但要把一種用到「手指在鍵盤上飛舞、不經思考地操縱文字」。操縱文字（Tip 28，學一種文字處理語言）：掌握一種能處理基本工具組搞不定的轉換的語言（Python、Ruby、awk、sed 之類），很多一次性的資料搬運、程式碼產生都能幾行解決。共同精神：把人從機械性重複裡解放出來。
3. 版本控制：對「一切」都用，它是專案級的時光機
Tip 28（書中編號）「Always Use Version Control」——永遠。即使你是單人、即使是一週的拋棄式原型、即使不是原始碼。VCS 是一個巨大的 undo 鍵、一台專案級時光機，帶你回到上週「code 還能編譯能跑」的好日子。作者甚至用版本控制管理這本書的文字。重點警告：共享資料夾不是版本控制——在網路硬碟/雲端硬碟上共用原始碼的團隊會不斷弄亂彼此、丟失變更、搞壞建置（就像在沒有同步機制下寫並行程式）。VCS 的真正威力在分支（隔離開發、是團隊工作流的核心）與「驅動自動化」（推送觸發建置/測試/部署）——這條會在第九章「務實上手工具」（EP11）升級成 CI/CD 的地基。
4. 除錯：系統化的解題，而非情緒事件
第三章字數最多的一節，全是可立刻用的策略。心態先擺正：Tip 29「Fix the Problem, Not the Blame」（修問題不是修責怪——不管是誰的錯，都是你的問題）、Tip 30「Don’t Panic」（別恐慌，「這不可能」的念頭一秒都別浪費，因為它就是發生了）。然後一套方法：先確保 code 乾淨編譯無警告；Tip 31「修 code 前先寫一個會失敗的測試」、讓 bug 能用單一命令重現；Tip 32「讀那該死的錯誤訊息」（別一看到紅字就跳進 code）；Tip 33「『select』沒有壞掉」（聽到蹄聲想馬不是斑馬——bug 幾乎都在你自己的新 code 裡，不是 OS/函式庫）；二分搜尋法（64 層堆疊最多 6 次定位、也用在輸入值與跨版本回歸）；橡皮鴨除錯（向一隻不會說話的鴨子逐步解釋你的 code，問題常自己跳出來）；Tip 34「不要假設，要證明它」。最後養成習慣：找出「為什麼這 bug 沒被更早抓到」、別處是否有同樣的 bug。
注意事項
⚠️ 這章最容易被聽眾當成「過時的工具清單」（純文字？vim？awk？）。請強調作者的真正主張不是「用哪個工具」，而是「投資在不會被某個 IDE 或某家廠商綁死的底層素養」。1999 年是這樣，2024 年連 AI 輔助編程的 context 也大多是純文字——這條反而更成立了。
⚠️ 「橡皮鴨除錯」「紙本工程日誌」聽起來很復古，別當笑話一筆帶過。它們背後是同一個認知科學原理：外化問題會切換你的大腦模式（從執行模式切到反思模式）。這個原理在第七章「聆聽蜥蜴腦」（EP8）會再出現，可預埋。
專家補充
💡 純文字 ＋ Unix 哲學這條，是整個現代開發工具鏈的隱形地基。Git diff、code review、CI log、Markdown 文件、Docker file、K8s YAML、甚至 LLM 的 prompt——全是純文字。作者 1999 年押的這個賭，二十多年後贏得乾乾淨淨。可以講「為什麼純文字打敗了所有花俏的二進位格式」。
💡 二分搜尋除錯法在 Git 裡有個內建神器叫 git bisect——你給它一個「好」的 commit 和一個「壞」的 commit，它自動二分幫你定位是哪個 commit 引入了 bug。這正是本書「跨版本回歸用二分法」的工具化。橡皮鴨除錯也已經是業界正式詞彙（rubber duck debugging），很多工程師桌上真的擺一隻鴨。
💡 「工程日誌」（紙本、手寫）這條很多人會跳過，但它連著一個更大的主題：把短期記憶卸載到外部。作者堅持用紙不用 wiki，理由是「手寫能切換大腦模式」——這跟現代「第二大腦／PKM」運動同源，只是工具不同。可當成一個反思性的小結尾。
討論問題
🎙️ 開場鉤子：「你會用幾種編輯器？這集作者的標準很簡單——你能不能流暢到，手指在動的時候腦子根本沒在想編輯這件事？工具如果還需要你分心去操作，它就還沒變成你雙手的延伸。」
🎙️ 自問自答：「為什麼除錯這麼讓人崩潰？」——因為我們把它當成『對自己能力的審判』而不是『一道題』。把那層自尊防禦關掉、改用『修問題不修責怪』的心態，除錯就只是解題，而解題是有系統方法的。
🎙️ 帶走的一題：「下次卡在一個 bug 超過十分鐘，先別改 code——找個人（或一隻鴨）逐行解釋你的 code 應該做什麼。賭你還沒講完就自己發現問題了。」
更大範圍關聯
- 與三經典的分工：《Clean Code》《Refactoring》談「程式碼長什麼樣」，本章談「你用什麼傢伙去寫和維護程式碼」。這是 Pragmatic 獨有的視角——三經典裡只有這本花整章談工具素養。
- Unix 哲學一脈：純文字 ＋ shell ＋ 小工具組合，直承《The UNIX Programming Environment》(Kernighan & Pike)、《The Art of Unix Programming》(Raymond)。本書是把 Unix 工具哲學翻譯給所有平台程式設計師的橋樑。
- 除錯方法論：系統化除錯接 David Agans《Debugging: The 9 Indispensable Rules》、John Ousterhout 的「先理解再修」。本書的「不要假設要證明」與科學方法同源——除錯就是做實驗驗證假設。
- 承先啟後：版本控制在這裡是個人工具，到第九章「務實上手工具」（EP11）會升級成驅動 CI/CD 的專案支柱；工程日誌的「外化思考」會在第七章蜥蜴腦（EP8）回來。
錄製建議
- 建議時長：約 24-26 分鐘（這章內容密、除錯一節特別長）。配比：純文字約 5 分、shell+編輯器+文字處理合併約 5 分（節奏帶快，講共同精神）、版本控制約 5 分、除錯約 9 分（主菜，策略多、橡皮鴨/二分法都好講）、工程日誌約 2 分當反思收尾。
- 討論策略：開頭用「工匠的工具箱」框住整章，避免變成零散的工具介紹。除錯是這集的高潮，建議用「心態 → 重現 → 定位 → 收尾」四階段講，每階段一兩個招式。刻意把「純文字二十年後反而更成立」「git bisect 是書裡二分法的工具化」這類現代回扣放進去，破除聽眾「這章過時了」的預設。
- 結尾預告 EP5「務實的偏執」——從「工具」轉到「防禦」：當你接受自己寫不出完美的軟體，你會怎麼自我防禦？