第 11 / 11 部 待錄

務實的專案

《The Pragmatic Programmer 務實的程式設計師》Podcast 準備稿：務實的專案

書名： 務實的程式設計師 The Pragmatic Programmer（Your Journey to Mastery, 20th Anniversary Edition） 作者： David Thomas & Andrew Hunt 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜The Pragmatic Programmer．小而穩的團隊、別崇拜貨物、你真正的頭銜是問題解決者 (11/11) 涵蓋範圍： 第9章 務實的專案（Topic 49-53：務實的團隊、不要切開椰子、務實的上手工具、取悅您的客戶、傲慢與偏見）

背景速覽

這是「啃一本大書」這一季的最終集，也是全書的收束章。前八章從個人哲學、方法、工具，走到專案啟動前的迷霧；第九章把所有務實技巧升級到專案與團隊層級，並用一個漂亮的高度收尾：原來我們做的根本不是「寫程式」，而是「解決問題、取悅使用者」。五個 Topic 把整本書的個人功夫（破窗、煮青蛙、知識組合、版控、測試、敏捷本質）一一升級成團隊版，最後落在「為你的作品簽名、以品質為傲」這個職業尊嚴的句點。

一句話重點

務實的個人技巧放到團隊層級會被加倍放大——維持小而穩定的團隊、別做貨物崇拜式地照抄別人的流程（做有效的事而非流行的事）、用版控/無情測試/完全自動化這三根支柱撐起持續交付、並認清你真正的頭銜不是「軟體工程師」而是問題解決者——目標從來不是交付程式碼，而是取悅使用者、解決他們的商業問題，並為你的作品自豪地簽名。

值得討論的重點

1. 務實的團隊：把個人功夫升級成團隊版

Tip 84「Maintain Small, Stable Teams」、Tip 85「Schedule It to Make It Happen」、Tip 86「Organize Fully Functional Teams」。團隊在作者眼中是「小型、大多穩定的獨立實體」——五十個人不是團隊是一群人；成員不斷被抽調、彼此不認識的，只是「在雨中暫時共用公車站的陌生人」。務實團隊不超過 10-12 人，成員少更換、彼此信任依靠。然後把前面整本書的個人原則一條條升級：不要容忍破窗（品質是團隊議題，最勤勉的人在不在乎品質的團隊裡也會失去熱忱；設「品質官」很荒謬——品質只能來自每個成員的個人貢獻，是內建的不是外加的）、煮青蛙（團隊比個人更容易被煮熟，因為人人假設「有別人在處理」——要鼓勵每個人監控範圍蔓延、時程縮短、新需求）、安排你的知識組合（改進與創新要排進時程，別讓工作清單只剩新功能）。Tip 86 還主張按功能（而非按職務 silo）組織完整團隊，讓團隊能端到端負責。

2. 不要切開椰子：別做貨物崇拜，做有效的事不是流行的事

Tip 87「Do What Works, Not What’s Fashionable」、Tip 88「Deliver When Users Need It」。貨物崇拜（cargo cult） 的故事：太平洋島民見過飛機帶來財富，陌生人走後，他們用藤蔓、椰子殼、棕櫚葉蓋了假機場假塔台，以為形式對了財富就會回來——但飛機沒來，他們模仿了形式卻沒掌握內容。我們常常就是那些島民：投資於容易看見的表面工程，幻想能召喚出底層的魔法。作者親見「聲稱做 Scrum」的團隊——每週才開一次每日站會、四週迭代拖成六到八週，但因為用了流行的敏捷工具就覺得沒問題。關鍵問句：你為什麼用這個方法/框架/技術？它真的適合手頭的工作嗎？還是只因為 Spotify、Netflix、Stripe 在用？考慮脈絡——你在同一個市場嗎？同樣的規模、文化、使用者群嗎？怎麼知道什麼有效？用最基本的務實技巧：試試看，小團隊試行、留好的丟壞的。（連 Netflix 成長期也沒在用他們現在的流程，幾年後又會做完全不同的事——那才是他們成功的秘訣。）真正的目標不是「做敏捷/做 Lean」，是能隨時交付可工作的軟體給使用者——年縮成月、月縮成週。

3. 務實的上手工具：版控、無情測試、完全自動化三支柱

第一版後作者想寫更多幫團隊的書，於是定義了每個團隊都需要、無論方法論語言技術棧的最基本元素——Pragmatic Starter Kit 三支柱。版本控制驅動一切（Tip 89「Use Version Control to Drive Builds, Tests, and Releases」——把建構所需的一切放進版控，讓建構機變臨時的、推送觸發 CI/CD、發布用 tag 指定，真正的持續交付不依賴任何一台機器）。無情且持續的測試（Tip 90「Test Early, Test Often, Test Automatically」、Tip 91「測試沒跑完，code 就沒完成」——務實程式設計師被驅使著現在就找到自己的 bug，免得日後被別人找到的恥辱；用細網單元測試抓小魚、粗網整合測試抓大鯊魚；Tip 92「用破壞者測試你的測試」——故意製造 bug 確認測試會報警，更高層用 Netflix Chaos Monkey 中斷服務測韌性；Tip 93「測狀態覆蓋，而非程式碼覆蓋」——跑過每一行不等於測過每一種狀態，用屬性測試探索意外狀態；Tip 94「每個 bug 只找一次」——bug 穿過網就加一個新測試把它網住，這也呼應第一章破窗）。完全自動化（Tip 95「不要使用手動程序」——人會犯錯、不可重現，建構、測試、部署全自動化）。

4. 取悅你的客戶：你真正的頭銜是「問題解決者」

Tip 96「Delight Users, Don’t Just Deliver Code」——全書情感最高的一節。我們存在的意義是取悅使用者，不是挖他們的資料、數他們的眼球、掏他們的錢包。而且即使準時交付可工作的軟體也不夠——光那樣不會讓他們高興。為什麼？因為使用者根本不在乎程式碼，他們有一個要在目標與預算下解決的商業問題。怎麼挖出他們真正的期望？問一個簡單問題：「專案完成一個月（或一年）後，你怎麼知道我們成功了？」 答案常出乎意料——一個「改善推薦」的專案，可能其實是用客戶留存率來評判的；一個「整合兩個資料庫」的專案，可能是用資料品質或成本節省來評判的。軟體只是達成商業目標的手段。所以作者下了全書最有力的結論：即使你的頭銜是「軟體開發者」或「軟體工程師」，你真正的頭銜應該是「問題解決者」——這就是務實程式設計師的本質。我們解決問題。

5. 傲慢與偏見：為你的作品簽名

Tip 97「Sign Your Work」——全書最後一條 Tip，也是收尾。過去的工匠以在作品上簽名為榮，你也該如此。但「簽名」這條規則有個陷阱：在某些專案，「程式碼所有權」會讓人變得有領地意識、不願碰共同基礎元件，專案最後變成一堆孤立小領地，你對自己的 code 有偏見、對同事的也有偏見——那不是我們要的。黃金法則（己所欲施於人）與開發者間的相互尊重是這條 Tip 運作的前提。另一面是匿名的危害：在大型專案裡匿名是草率、懶惰、糟糕 code 的溫床，太容易把自己當齒輪、產出無盡的藉口型狀態報告。程式碼必須有人負責，但不必是個人——Kent Beck 的 XP 推薦共同所有權（搭配結對編程防範匿名的危害）。最終的境界：你的簽名應該被認可為品質的指標——人們看到你的名字出現在一段 code 上，就期待它是扎實的、寫得好的、測過的、有文件的。一份真正專業的工作，由一位專業人士——一位務實的程式設計師——所寫。

注意事項

⚠️ 「不要切開椰子」很容易被聽成「所以別學 Spotify/別用 Scrum」。作者反的是不顧脈絡地照抄形式（貨物崇拜），不是反對學習別人。真正的訊息是「先理解為什麼有效、再用小規模試行驗證它適不適合你」。連被崇拜的公司自己當年也不是這樣做的——重點是「持續試驗與調適」這個能力，而非任何特定流程。

⚠️ 「為你的作品簽名／程式碼所有權」別講成「我的 code 神聖不可侵犯」。作者明確警告領地意識的危害，並推崇共同所有權。「簽名」的精神是為品質負責的自豪感，不是佔地為王的防衛心——這條界線是這節的核心張力，務必講清楚。

專家補充

💡 「Pragmatic Starter Kit 三支柱」（版控/測試/自動化）在 1999 年是前瞻主張，2024 年已是 DevOps 與《Accelerate》（Forsgren et al.）量化驗證的「精英團隊四大關鍵指標」的基礎。本書 1999 年就把「版控驅動建構與發布」寫進來，比 CI/CD 成為主流早了十年——又一次證明它押的方向有多準。可以講「這本書如何預言了 DevOps」。

💡 「你真正的頭銜是問題解決者」這條，與 John Ousterhout、Uncle Bob 乃至整個軟體工匠運動的精神完全一致，但本書講得最動人。「專案成功一年後你怎麼知道？」這個提問是產品思維（product thinking）的精髓——把工程師從「實作規格的人」提升為「對商業結果負責的人」。這也與第八章「沒人知道自己要什麼、程式設計師幫人搞清楚」（EP10）首尾呼應：從幫人搞清楚需求，到對商業結果負責，是同一條「超越 code」的線。

💡 「為你的作品簽名」作為全書最後一條 Tip，刻意呼應第一章第一句「這本書是關於你的」——整本書從「擁有你的職涯」開始，到「為你的作品自豪地簽名」結束，形成一個完整的圓。這是一本講「如何成為一位你願意署名的專業人士」的書。收尾時值得把這個首尾呼應點出來，給整季一個漂亮的句號。

討論問題

🎙️ 開場鉤子：「想像一個團隊，每週開一次『每日』站會、四週的 sprint 拖成八週，但他們很安心，因為用了一個很潮的敏捷工具。這集要講的是：他們蓋了一座椰子殼做的假機場，然後等飛機降落。而我們，常常就是那些島民。」

🎙️ 自問自答：「準時交付了可以跑的軟體，客戶就會滿意嗎？」——本書的答案是不會。因為客戶根本不在乎你的 code，他們在乎的是一個商業問題有沒有被解決。問一句『一年後你怎麼知道我們成功了』，你會發現真正的成功指標，常常根本不在那份規格書裡。

🎙️ 帶走的一題：「看一眼你最近交付的東西——如果要你自豪地把名字簽在上面，當成『這代表我的專業水準』公開展示，你願意嗎？如果有一絲猶豫，那一絲猶豫就是你下一個該修的地方。」

更大範圍關聯

  • 全書收束 ＋ 首尾呼應：本章把前八章的個人原則全部升級成團隊版（破窗、煮青蛙、知識組合、版控、測試、敏捷本質），並用「為你的作品簽名」呼應全書第一句「這本書是關於你的」——整本書是一個從「擁有職涯」到「署名負責」的完整圓。
  • 與 DevOps/精英團隊研究：三支柱（版控/測試/自動化）接《Accelerate》《The DevOps Handbook》、CI/CD、Chaos Engineering（書中直接點名 Netflix Chaos Monkey）。本書是這條工程文化的早期源頭之一。
  • 與三經典 ＋ 軟體工匠運動：「為作品簽名、以品質為傲」直接呼應《Clean Coder》(Uncle Bob) 的職業倫理、軟體工匠宣言（Software Craftsmanship Manifesto）；「共同所有權 ＋ 結對」接 Kent Beck 的 XP。本系列可與 Reading Uncle Bob 互文收尾。
  • 產品思維：「取悅使用者、你是問題解決者」接《Inspired》(Cagan)、《The Lean Startup》——工程師對商業結果負責，是現代產品工程的核心。

錄製建議

  • 建議時長：約 25-28 分鐘（最終集，內容多且要收束整季）。配比：務實的團隊約 6 分（個人原則升級團隊版）、不要切開椰子約 6 分（貨物崇拜故事是亮點）、三支柱約 6 分（版控/測試/自動化，DevOps 的源頭）、取悅客戶約 6 分（「一年後你怎麼知道成功」「你是問題解決者」是情感高潮）、傲慢與偏見約 4 分（為作品簽名，全書句點）。
  • 討論策略：用「個人 → 團隊 → 使用者」的放大鏡主線——前面整本書講你自己，這章講你和團隊，最後落到你和使用者。把「取悅客戶」與「為作品簽名」當作全集甚至全季的雙重高潮：一個對外（你為誰而做）、一個對內（你是誰）。最後務必點出「全書首尾呼應」這個圓，給整季一個有重量的句號。
  • 這是整季最終集，記得花 1-2 分鐘回顧整季走過的路（哲學 → 方法 → 工具 → 偏執 → 解耦 → 並行 → 編碼 → 專案啟動前 → 專案），並把這本書的終極訊息留給聽眾：技術會過時，但「擁有你的職涯、以工匠之心解決問題、為你的作品署名」這套態度，二十年不變。