🎯 什麼情境該想到我
當你覺得自己或團隊停滯不前、舊習慣阻礙新技術、問題只看到表面、或者工作節奏混亂的時候。
章導言引 Will Rogers：「即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。」軟體業像一台跑步機，而「只有一个人会为你负责——你自己」。書的論點是：新技術多半是增量的變化，持續跟上的話，只需要學增量。
| 習慣 | 良策 |
|---|---|
| 跟蹤變化 | 不需要精通所有技術，但要清楚行業的動向 |
| 對團隊投資 | 用午餐會議增進每個人的知識 |
| 懂得丟棄 | 學習新的東西，丟棄會阻止你前進的舊習慣 |
| 打破砂鍋問到底 | 不停地問為什麼，直到明白問題的根源 |
| 把握開發節奏 | 保持事件之間穩定重複的間隔 |
出處：Subramaniam & Hunt《高效程式設計師的 45 個習慣：敏捷開發修煉之道》（Practices of an Agile Developer）。站內的原書是掃描版 PDF，引文依 OCR 結果核對，保留原書簡體字。每個習慣在書中都有固定結構：魔鬼的誘惑（一句錯誤但誘人的想法）→ 良策（書中粗體的一句話建議）→ 內文 → 切身感受 → 平衡的藝術（別做過頭）。
⚙️ 怎麼用（逐項）
跟蹤變化
Keep Up with Change 什麼時候會冒出來：覺得技術跑太快自己快被淘汰／不知道該不該追這個新東西／想建立持續吸收新知的管道／每天冒出的新名詞完全跟不上
魔鬼的誘惑：「继续用你熟悉的语言做你的老本行吧，你不可能跟上技术变化的脚步。」
良策：「跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。」
書中重點：
- 假設你 1995 年畢業，懂 C++、聽過 Java 和網際網路；2005 年重新回到業界，會發現 Java 生態、.NET、XML、SOA 等大量新東西。但如果一路跟上來，學 .NET 就不難——「你不需要一口气爬上10楼，而需要一直在攀登」。
- 只掌握工作需要的技術不夠——工作可能被外包，技術也可能過時。
- 五個具體做法：
- 迭代和增量式學習：每天固定一段時間；聽到陌生的術語先記下來，之後再深究。
- 了解最新行情：社群、郵件列表、技術部落格。
- 參加本地使用者社群。
- 參加研討會。
- 如飢似渴地閱讀：技術與非技術的書、期刊。
切身感受：「你能嗅到将要流行的新技术……如果必须要把工作切换到一种新的技术领域，你能做到。」
平衡的藝術：
- 許多新想法從未成熟為有用的技術——要正確把握投入的精力。
- 不可能也不需要精通每一項技術；在某些方面成為專家，就能用同樣的方法成為新領域的專家。
- 要明白為什麼需要這項新技術：它解決什麼問題？
- 避免只因為想學就把應用程式換成新技術。「开发一个小的原型系统，是对付技术狂热者的一剂良药。」
在今天的樣子：書中「每天固定一段時間」的做法，和 工具-投資自己持續學習 的「定期定額」是同一件事。最後一條平衡的藝術，與 合理地使用技術 呼應。
對團隊投資
Invest in Your Team 什麼時候會冒出來：只有自己在進步團隊沒跟上／想辦讀書會或午餐分享／學到好東西想推廣給大家／團隊整體水準一直拉不起來
魔鬼的誘惑：「不要和别人分享你的知识——自己留着。你是因为这些知识而成为团队中的佼佼者。」
良策：「提供你和团队学习的更好平台，通过午餐会议可以增进每个人的知识和技能。」
書中重點：
- 「一个学习型的团队才是较好的团队。」團隊要有共同的術語才能有效溝通；上完課不用就會忘，所以要分享。
- 午餐會議的具體做法：
- 每週固定一天（例如星期三；最好不要選星期一或星期五）。
- 排在午餐時間，避免和其他會議衝突，不需要特別申請；自帶午餐，降低成本。
- 每週由一個人主持，先講 15 分鐘，再開放討論：這個主題對我們專案的意義、好處、自己應用的例子。
- 側欄〈每個人都比你厲害嗎？那太好了！〉：爵士吉他手 Pat Metheny 說：「总是要成为你所在的那个乐队中最差的乐手，如果你是乐队中最好的乐手，就需要重新选择乐队了。」
切身感受：「这样做，会让每个人都觉得自己越来越聪明。」
平衡的藝術：
- 讀書小組逐章共讀很有用，但要選好書。
- 不是每場講座都精彩，但要未雨綢繆：「諾亞造方舟時還沒下雨。」
- 講座要在團隊裡進行；搬到禮堂、請外燴、用正式簡報，反而減少討論。
- 堅持有規律地舉行：「持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。」
- 主題不限技術，專案估算、溝通技巧也有幫助。
- 午餐會議不是設計會議；具體的設計問題留給設計會議。
在今天的樣子：遠端團隊可以用固定的線上分享時段取代午餐會議。把分享內容寫成內部文件，也是一種對團隊的投資（見 成為指導者）。
懂得丟棄
Know When to Unlearn 什麼時候會冒出來：還在用十年前的老方法解新問題／熟悉的做法其實已經不適用了／明知該換做法卻放不下慣性／過去的成功經驗反而變成阻礙
魔鬼的誘惑：「那就是你一贯的工作方法……很明显它是最好的方法。真的，从那以后就不要再改变了。」
良策：「学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，汽车要比马车车厢强得多。」
書中重點：
- 作者 Andy 剛開始寫程式時，主記憶體大約只有 48KB，必須把程式切塊換入換出；還要手動調整組合語言輸出——這些在今天都沒有必要了。
- Andy 看過一段 C 程式碼：一個大迴圈，印出來有 60 頁，因為作者「不相信」編譯器的最佳化，自己手動展開。「现在，开发者的时间才是紧缺和昂贵的资源。」
- 管理者拒絕花 500 美元買一台建置用的機器，卻寧願付好幾萬美元的人工費。
- 常見的現象：用 C 的方式寫 Java、用 VB 的方式寫 C#。
- 丟棄的第一步是意識到自己還在用過時的方法——這也是最難的一步。學新語言時，使用它推薦的工具，做一個完全不同類型的專案，轉換期間完全不用舊語言的工具。
切身感受：「新技术会让人感到有一点恐惧……已有的技能和习惯为你打下了很好的基础，但不能依赖它们。」
平衡的藝術：
- 要果斷丟棄舊習慣；一味遵循過時的習慣會危害職業生涯。
- 不是完全忘記舊習慣，而是只在適當的情境下使用。
- 整理所用語言的熟悉特性，比較它們在新語言中有什麼不同。
在今天的樣子：
- 用 Java 的方式寫 Go 是最常見的例子：到處定義介面、深層的繼承式抽象、getter/setter。Go 的習慣是小介面、在使用端定義、組合而非繼承（見 工具-Go介面小而隱式）。
- 蒙格的 避免不一致傾向 解釋了為什麼丟棄這麼難：人腦傾向維持已經建立的習慣。
打破砂鍋問到底
Question Until You Understand 什麼時候會冒出來：聽不懂但不好意思開口問／只知道要這樣做卻不知道為什麼／想追到問題真正的根源／別人給的說法感覺沒說到底
魔鬼的誘惑：「接受别人给你的解释。别人告诉你问题出在了什么地方，你就去看什么地方。」
良策：「不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。」
書中重點：
- 即使有人說「問題一定在這個模組，其他可以忽略」，你仍然需要了解系統的全局。
- 醫生的比喻：一位紐約的病人高燒、出疹、頭痛、關節痛，看起來像流感或麻疹。全面詢問之後才發現，他剛從南美洲度假回來——可能是登革熱。
- 《第五項修練》建議理解問題時要連續問 5 次以上的「為什麼」。書中的例子：工廠經理看到地板上有油漬，只命令清掃、責怪清潔人員。顧問一再追問「為什麼地板上會有油漬？」，最後發現根源是採購政策寫得不清楚，導致大量買進了有缺陷的墊圈。
- 值得追問的話：「只要每週重啟一次系統，就沒有問題了」「必須連續建置 3 次才能成功」「我們的使用者根本不想要那個功能」——真的嗎？為什麼？
切身感受：「这就好比是从矿石中采掘贵重的珠宝……你要能感觉到真正地理解了问题，而不是只知道表面的症状。」
平衡的藝術：
- 問「為什麼」要問到點子上：車子發不動卻問輪胎有沒有問題，沒有幫助。
- 可能被反問「你為什麼問這個？」——提問前先想好理由。
- 「这个，我不知道」是一個好的起點，應該由此進一步調查，而不是對話的結束。
在今天的樣子：
- 事故的根本原因分析；但注意 工具-無指責事後檢討 提到的限制：「5 個為什麼」容易導向單一的因果鏈，實際的事故通常有多個促成因素。
- 「每週重啟一次就好」是典型的記憶體洩漏或資源洩漏症狀，值得追到底。
把握開發節奏
Find the Rhythm 什麼時候會冒出來：工作忙起來要命閒起來發呆／每次都要到期限前才開始爆衝／想讓開發有可預期的韻律／團隊步調時快時慢難以持續
魔鬼的誘惑：「我们很长时间没有进行代码复审，所以这周会复审所有的代码。此外，我们也要做一个发布计划了，那就从星期二开始，用3周时间……」
良策：「解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。」
書中重點：
- 不成功的專案，常常是隨意安排工作。「上帝发明了时间，就是为了防止所有事情同时发生。」
- 每天下班前：執行測試並提交當天完成的程式碼。如果很晚了，手上只是嘗試性的程式碼，也許最好刪掉，第二天重新開始。
- 側欄〈時間盒〉：設定短而不可延長的期限。可以放棄部分任務，但期限不變——「你不会改变时间，但是你可以改变功能」。設計討論也要設時間盒，時間到了就必須做決定。
- 最大的節拍是迭代，一般 1～4 週，每個迭代的長度要相同。每天固定時間、地點開站立會議。
切身感受：「项目开发需要有一致和稳定的节奏……如果知道什么时候开始下一个节拍，跳舞就会更加容易。」
平衡的藝術：
- 每天結束時測試、提交，沒有殘留的程式碼。
- 不要經常加班。
- 迭代長度固定；剛開始可以調整，找到最舒服的長度之後就要堅持。
- 節奏太密集會讓人精疲力竭；與其他團隊合作時可能需要放慢。
- 小成功也是大激勵，要慶祝每次成功。
在今天的樣子：
- 「每天提交、每天都能建置」就是主幹開發的前提（見 工具-部署管線與持續交付）。
- 時間盒的精神在 工具-降低在製品WIP 中也看得到：固定的節奏讓工作量變得可預測。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 學習要和工作連結：書中多次強調「要明白為什麼需要這項新技術」。為了學而學、把新技術硬塞進專案，會傷害專案。
- 節奏不等於加班：書中明確說不要經常加班。穩定的節奏是為了可持續，不是為了壓榨更多產出。
🔗 相關工具
- 工具-投資自己持續學習 —— 從本頁萃取的即用工具卡
- 不用就忘傾向 —— 蒙格對「為什麼要持續練習」的解釋
- 高效程式設計師的45個習慣 —— 書卡