第 1 / 6 部 待錄

溝通的哲學與經濟學

《實作模式》Podcast 準備稿：溝通的哲學與經濟學

書名： 實作模式 Implementation Patterns 作者： Kent Beck 系列： 設計品味系列（程式碼層次的設計直覺） 公開標題建議： 設計品味系列｜Implementation Patterns．第一集：程式碼是寫給人看的，順便給機器跑 (1/6) 涵蓋範圍： 第 1 章「導論」、第 2 章「模式」、第 3 章「程式設計理論」、第 4 章「動機」

背景速覽

這是「設計品味系列」的開場書。Kent Beck 是極限編程（XP）、測試驅動開發（TDD）的提出者，也是設計模式社群的元老之一。這本《實作模式》談的不是宏觀架構，而是最微觀的尺度——你每隔幾秒鐘就在做的決定：這個變數怎麼命名、這段邏輯放哪個方法、要不要拆一個類別出來。今天這四章是全書的世界觀地基，把「為什麼這些雞毛蒜皮的決定值得認真對待」講清楚。

一句話重點

程式碼最主要的讀者是人，不是電腦；所以寫程式的第一性原理是「溝通」，而這不是道德訴求，是冷冰冰的經濟學——軟體大部分的成本發生在你寫完之後。

值得討論的重點

重點一：這本書站在 Design Patterns 和語言手冊「之間」的縫隙

先幫聽眾定位。市面上講設計的書，要嘛很高——《Design Patterns》談物件之間怎麼互動，那是你一天做幾次的決定；要嘛很低——Java 語言手冊告訴你語法「能做什麼」，但從不告訴你「為什麼」要這樣寫。Kent Beck 說，這中間有一大片沒人認真寫的縫隙：那些你每隔幾秒就在做、做完就忘、卻決定了程式碼長相的決定。命名一個變數、決定一個迴圈怎麼寫、要不要把這兩行抽成方法。

他在書裡點名了 77 個明確命名的模式。但別被「模式」這個詞嚇到——他講的模式不是 Singleton、Factory 那種大寫的 Design Pattern，而是「力量的模式（Pattern of Forces）」。意思是：每次你寫迴圈，背後拉扯你的那組力——易讀、易寫、易驗證、易修改、夠快——是可預測地反覆出現的。模式就是針對這組反覆出現的力，給你一個「預設答案」，讓你不用每次都從頭辯論一遍。就像鋪床：你有一套既定流程，不用每天重新發明怎麼鋪，把腦力留給真正有趣的問題。

重點二：三層金字塔——價值觀、原則、模式

這是第 3 章、也是全書最重要的心智模型。Kent Beck 把他的整套程式設計哲學拆成三層：

  • 價值觀（Values）：最頂層，三個——溝通、簡單、彈性。它影響每一個決定，但太抽象，沒辦法直接拿來用。
  • 原則（Principles）：中間層，六個——局部影響、最小化重複、邏輯與資料放一起、對稱、宣告式表達、變動頻率。它比價值觀具體，是價值觀和模式之間的橋。
  • 模式（Patterns）：最底層，77 個具體做法。模式說「做什麼」，價值觀提供「動機」，原則幫你「把動機翻譯成行動」。

為什麼這個三層結構重要？Kent Beck 給了一句很犀利的話：如果兩個人連原則都不同意，那爭論大括號該放哪一行是解決不了根本問題的。 很多 code review 的爭吵之所以無解，是因為大家在最表層的「模式」吵，但真正的分歧在更深的「價值觀」或「原則」。把這三層拆開，你才知道這次的歧見到底卡在哪一層。

三個價值觀裡，我想特別講「彈性」。Kent Beck 說，彈性是被拿來替最多爛設計辯護的藉口。他舉了一個例子：為了拿一個常數，有人寫程式去查環境變數拿目錄名稱、再去那個目錄的檔案裡找常數值——為什麼這麼複雜？因為「彈性」。但如果那個常數永遠不變，這些彈性全是成本、零收益。他的結論很重要：真正的彈性來自簡單和完整的測試，不是來自你今天投機式想像的擴充點。

重點三：成本公式——維護費比開發費貴，而維護的瓶頸是「讀懂」

第 4 章把前面的哲學換成了會計語言，這段我覺得是全書最有說服力的部分。他把軟體成本拆成：

總成本 = 開發成本 + 維護成本

然後業界血淋淋的經驗是：維護成本遠大於開發成本。再往下拆維護成本：

維護成本 = 理解成本 + 修改成本 + 測試成本 + 部署成本

關鍵在第一項。Kent Beck 說：當你知道該改哪裡，改本身通常很快；真正貴的是「搞懂這段現有的程式碼到底在幹嘛」。而修改程式碼時，你花在「讀舊程式碼」的時間，遠遠多於「寫新程式碼」。所以結論順理成章：要讓軟體便宜，就要讓它易讀。「為他人寫易讀的程式碼」不是情懷，是直接砍掉維護成本裡最大那一塊的手段。

重點四：「有意識地編程」——慢下來，看清自己在想什麼

第 1 章有個很私密的告白我很喜歡。Kent Beck 說他寫了很多年程式之後，驚訝地發現：雖然他的決策很流暢——這個方法該叫什麼、這段邏輯該放哪個物件——但他講不出為什麼。決策是對的，但它是直覺，不是知識。

他講「透過程式碼溝通」需要三步：第一，有意識地編程——別再假裝你是憑直覺寫，慢下來去察覺自己在想什麼；第二，重視他人——相信「別人和我一樣重要」，這是一個有意識的決定，需要練習；第三，在實踐中體現——用實作模式把這份在意變成具體動作。這跟整本書的標題呼應：模式存在的意義，是把那些「老手憑直覺做對」的事，編碼化成「可以講清楚、可以教、可以討論」的東西。

注意事項

⚠️ 「溝通優先、為人而寫」這個大方向我完全認同，但要小心它被濫用成「過度雕琢」的藉口。有人會花半小時糾結一個變數名、為了「溝通」把簡單的東西包成三層方法。Kent Beck 自己其實有解藥——他在「簡單」這個價值觀裡明確說：少即是多，能刪的元素就刪。所以正確的姿勢是：溝通和簡單通常是同盟，不是對手。當你為了「溝通」反而把程式碼弄複雜了，多半是你搞錯方向了。書裡只有極少數情況他才選「溝通優先於簡單」。

⚠️ 這本書 2007 年出版，範例全是 Java，而且是「保守的 Java 子集」——他刻意避開邊緣特性。所以有些具體模式在今天會過時：比方說書裡花了不少篇幅講 getter/setter、Versioned Interface 的向下轉型，這些在有 record、sealed class、pattern matching 的現代語言裡有更乾淨的做法。聽眾要帶走的是背後的力與原則，而不是逐字照抄 2007 年的 Java 寫法。

⚠️ 「維護成本遠大於開發成本」是個強假設，它預設了「這段程式碼會活很久、會一直被改」。但 Kent Beck 自己在書裡也誠實補了一句：幾乎不需要維護的專案，應該用一套和這本書完全不同的模式。 一次性腳本、驗證用的 prototype、活不過三個月的東西，硬套這套「為長期溝通而寫」的標準，本身就是一種浪費。先判斷你的程式碼會不會活很久，再決定要不要認真。

專家補充

💡 這套「價值觀／原則／模式」三層結構，其實是 Kent Beck 的招牌思考方式。他在《Extreme Programming Explained》裡用的也是同一招——XP 也是先講 Values（溝通、簡單、回饋、勇氣），再講 Principles，最後才是 Practices（具體實踐如 TDD、結對編程）。所以你可以把這本書理解成「XP 的價值觀，下沉到一行一行程式碼的尺度」。同一個腦袋，換了放大倍率。

💡 他提到 Knuth 的「Literate Programming」（文學編程）給他的啟發很值得展開。他和 Ward Cunningham 試著把 Smalltalk 裡最乾淨的一段程式碼改寫成「像故事一樣可讀」，結果發現一個有趣現象：每當一段邏輯難以解釋，重寫那段程式碼，比解釋它為什麼難懂更容易。 這個發現顛覆了他對編程的看法——「難以溝通」本身就是一個 code smell，是程式碼在向你求救。順帶一提，Ward Cunningham 後來發明了 Wiki，也是「為了讓人更容易協作溝通」這條線上的人。

💡 「有意識地慢下來、強迫自己寫下正在遵循的模式」這件事，Kent Beck 在第 4 章給了真實數據。他寫第一本模式書（1996 年的《Smalltalk Best Practice Patterns》）時，強迫自己每打一行程式碼前先寫下遵循的模式。第一週很痛苦——每一分鐘的編程前都有一小時的寫作；第二週大部分基本模式就位了；第三週，他的編程速度比以前還快。這其實就是「刻意練習」在程式設計上的應用——把隱性知識顯性化，短期變慢，長期變快又變穩。

討論問題

🎙️ 回想你最近一次接手別人的程式碼。你花在「讀懂它在幹嘛」的時間，跟真正動手改的時間，比例大概是多少？如果理解成本真的是維護的最大瓶頸，你現在的程式碼有為下一個接手的人省下這筆錢嗎？

🎙️ Kent Beck 說「彈性是被拿來替最多爛設計辯護的藉口」。回想你上一次以「為了之後好擴充」為理由加的抽象層——它後來真的被用到了嗎？還是它只是一筆「為從沒到來的未來預付的帳」？

🎙️ 如果把「價值觀／原則／模式」三層套到你團隊上一次 code review 的爭吵——你們到底是在吵模式（大括號、命名風格），還是其實卡在更深的原則或價值觀分歧？把它拆開來看，那場爭吵會不會更好解？

🎙️ Kent Beck 承認自己寫了多年程式才發現「我講不出我為什麼這樣決定」。你呢？挑一個你今天做的編程決定，試著向想像中的聽眾解釋「為什麼」——你解釋得出來嗎？

更大範圍關聯

  • 接《Clean Code》：Uncle Bob 的《Clean Code》和這本書是同一條河的兩條支流——都主張「程式碼是寫給人看的」「命名是溝通的核心」。但氣質不同：Clean Code 比較像「規矩手冊」，告訴你該怎麼做；Kent Beck 這本更像「思考框架」，先給你價值觀和原則，讓你自己長出判斷。兩本一起讀，一個給你戒律，一個給你為什麼。

  • 接 John Ousterhout《A Philosophy of Software Design》：Ousterhout 的核心敵人是「複雜度」，跟 Kent Beck 的「簡單」價值觀根本是同一件事。但兩人有個有趣的分歧——Ousterhout 對「方法切太小、太多淺方法」很警惕，而 Kent Beck 偏好把東西拆得很細很小。這個張力很適合在後面講「方法」那集拿出來辯。

  • 接 Martin Fowler《Refactoring》：Fowler 和 Kent Beck 是長期戰友（Fowler 書裡很多東西受 Kent 影響）。這本書提供「為什麼要把程式碼整理乾淨」的價值觀，Refactoring 提供「具體怎麼安全地整理」的手法。Kent Beck 反覆強調的「先讓它跑、再基於事實去結構化」，本質上就是重構的精神。

  • 接 TDD：別忘了 Kent Beck 就是 TDD 之父。這本書裡「用自動化測試取代註解來溝通」「測試是有價值的設計練習」這些觀點，是 TDD 哲學的延伸——測試不只是抓 bug，它是一種溝通媒介、一種設計工具。

錄製建議

目標約 20 分鐘，單人主講。建議節奏：

  • 0–3 分：系列開場 + 這本書定位。一句話交代「設計品味系列開場，這本是 Kent Beck 的《實作模式》，談的是最微觀的尺度——你每幾秒就在做的編程決定，全系列約 6 集」。用「Design Patterns 和語言手冊之間的縫隙」這個比喻幫聽眾找到座標。
  • 3–8 分：價值觀／原則／模式三層金字塔。這是全書最有用的心智模型，講慢一點，三層各舉一個例子。特別把「彈性是替爛設計辯護的藉口」這句金句講透。
  • 8–13 分：成本公式。把兩個公式口頭講一遍（總成本、維護成本），重點落在「維護的瓶頸是理解，所以易讀才便宜」。這段是把哲學翻成會計語言，最有說服力。
  • 13–17 分：辯證時間（本系列招牌）。誠實面對「這是 2007 年的 Java」「維護假設不是永遠成立」。明確告訴聽眾：帶走的是力與原則，不是逐字的 Java 寫法。
  • 17–20 分：收尾 + 預告。用「有意識地編程、慢下來才會變快」的故事收尾，預告下一集進入第一個大主題——「類別」，從命名講到繼承 vs 委派。

口氣提醒：這集很哲學，容易講得乾。多用「你一定遇過接手爛 code 讀到崩潰」這種共感切入，把抽象的價值觀掛回聽眾的真實痛點。