高效程式設計師的45個習慣（敏捷開發修煉之道）

📌 30 秒摘要（Layer 3）

把敏捷從口號變成 45 個可執行的日常習慣：從態度（對事不對人、勇於嘗試）、到節奏（短迭代、持續獲得回饋）、到協作（結對、程式碼共有）、到成長（持續投資自己）。核心精神是擁抱變化、用短週期的回饋逼近正確，而不是一次規劃到底。

🗺 心智圖（Canvas）

高效程式設計師的45個習慣
⚡ 高效程式設計師的

45 個習慣
擁抱變化 需求會變是常態，用短迭代 + 持續回饋去適應
持續獲得回饋 小步交付、常給客戶看、自動化測試——越早發現偏差越便宜
「敏捷不是做得更快，而是更快地發現自己做錯了。」
工具-投資自己持續學習
🎯 什麼情境該想到我

當你感覺「技術一直在變、自己在原地踏步、怕被淘汰」，或者想有系統地持續成長的時候。

出處：《高效程式設計師的 45 個習慣》第 3 章「學無止境」。分工：這張是即用版；原書五個學習習慣的完整內容（跟蹤變化、對團隊投資、懂得丟棄、打破砂鍋問到底、把握開發節奏）→ 學無止境。具體的學習計畫怎麼訂 → 工具-務實學習投資計畫。

⚙️ 怎麼用

原書的出發點

章導言引 Will Rogers：「即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。」軟體業像一台跑步機，而「只有一个人会为你负责——你自己」。

原書的論點：新技術多半是增量的變化——持續跟上的話，只需要學增量。「你不需要一口气爬上10楼，而需要一直在攀登。」

原書「跟蹤變化」的五個做法

迭代和增量式地學習：每天固定一段時間；聽到陌生的術語先記下來，之後再深究。

了解最新行情：社群、郵件列表、技術部落格。

參加本地的使用者社群。

參加研討會。

如飢似渴地閱讀：技術與非技術的書。

把知識當投資組合

《程式設計師的思維修煉》把同樣的觀念做成一套方法（見工具-務實學習投資計畫）：

定期投資：像定期定額一樣，固定時間持續投入。

多樣化：深耕主力技術，也接觸新語言、非技術領域。

主動管理：定期評估，淘汰沒有效益的項目。

往哪裡投

能帶來「專長」的方向：無法靠培訓取代的知識（見工具-累積特定知識）。

能放大的方向：寫作、開源、工具——學到的東西可以變成槓桿（見工具-三種槓桿）。

把學習搬進本業：用選工作、挑任務來換技能（見工具-為學習而工作）。

在工程師身上的樣子

做法範例
每天固定時間每天早上 30 分鐘讀一篇技術文章或一段原始碼
記下陌生術語在筆記裡維護一份「聽過但不懂」的清單，每週挑一個深入
教別人把學到的東西寫成內部分享——《45 個習慣》的「對團隊投資」
用在工作上學一個新工具，就在下一個專案的小地方用它

🧪 我實際套用的紀錄

2026-07-15：（待填）

⚠️ 注意 / 什麼時候不適用

要知道為什麼學：原書提醒「要明白為什麼需要這項新技術——它解決什麼問題」；避免只因為想學就把專案換成新技術。

不可能精通所有技術：在某些方面成為專家，就能用同樣的方法成為新領域的專家。

知識會折舊：停止學習不是「維持現狀」，而是相對退步。

🔗 相關工具

學無止境 —— 原書第 3 章的完整展開

工具-務實學習投資計畫 —— 怎麼訂計畫

工具-累積特定知識 —— 往哪個方向投

工具-玩長期遊戲與複利 —— 為什麼定期投入有效

工具-對事不對人的協作
🎯 什麼情境該想到我

當技術討論或 code review 變成人身衝突、大家開始護短，或者提意見怕傷感情的時候。

出處：《高效程式設計師的 45 個習慣》習慣 3「對事不對人」。分工：這張是即用版；原書的完整內容（魔鬼的誘惑、三種回應的對照、四個技巧、平衡的藝術）→ 態度決定一切：對事不對人。

⚙️ 怎麼用

良策

「对事不对人。让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。」（旁註：消極扼殺創新）

三種回應的對照（原書的例子）

同事提出一個新方案：

「那样很蠢！」——否定個人能力。

「那样很蠢，你忘记考虑它要线程安全。」——指出缺點，但仍然在否定；而且如果對方回「它本來就跑在自己的執行緒上」，你會很難堪。

「谢谢。但是我想知道，如果两个用户同时登录会发生什么情况？」——只有這種有效：提出具體的顧慮，而不是下結論。

讓討論保持對事的四個技巧（原書）

設定最終期限：例如午餐前做出決定。沒有最好的答案，只有更合適的。

逆向思維：先看方案的優點，再努力從反面去認識它。

設立仲裁人：主持人確保每個人都有發言機會，防止明星員工主導；仲裁人不發表自己的意見。

支持已經做出的決定：客戶不在乎是誰的主意，結果才重要。

平衡的藝術（節錄）

盡力貢獻想法，沒被採納也不需要生氣。

「資料庫廠商可能會倒閉」這種說法不夠，要評估發生的可能性。

只有更好，沒有最好——不存在「最佳實踐」，只有特定條件下更好的實踐。

不帶情緒不等於盲目接受：用合適的詞和理由說明你為什麼不同意。

在 code review 裡的樣子

✗ 對人 ✓ 對事
「你又忘了處理錯誤。」「這個函式在 ctx 被取消時會回傳什麼？」
「這寫法太菜了。」「這裡用 map 會不會比較快？這個 slice 可能有幾千個元素。」
「誰寫的這段？」（在事故中）「這段程式碼在什麼情況下會拿到空值？」

🧪 我實際套用的紀錄

2026-07-15：（待填）

⚠️ 注意 / 什麼時候不適用

對事不對人不等於不在乎人的感受：用尊重的語氣談事，兩者兼顧。

需要心理安全作為前提：在會懲罰錯誤的團隊裡，再怎麼強調對事不對人，大家還是不敢開口（見工具-心理安全感）。

明顯的問題要直接說：安全漏洞、會造成事故的 bug，提問式的說法可能太隱晦。

🔗 相關工具

態度決定一切 —— 原書第 2 章的完整展開

工具-心理安全感 —— 前提條件

工具-無指責事後檢討 —— 同一原則在事故場景的制度化版本

用提問代替命令 —— 卡內基的版本

🧭 態度決定一切

[[態度決定一切#做事|做事]]

[[態度決定一切#欲速則不達|欲速則不達]]

[[態度決定一切#對事不對人|對事不對人]]

[[態度決定一切#排除萬難奮勇前進|排除萬難奮勇前進]]

📚 學無止境

[[學無止境#跟蹤變化|跟蹤變化]]

[[學無止境#對團隊投資|對團隊投資]]

[[學無止境#懂得丟棄|懂得丟棄]]

[[學無止境#打破砂鍋問到底|打破砂鍋問到底]]

[[學無止境#把握開發節奏|把握開發節奏]]

📦 交付用戶想要的軟件

[[交付用戶想要的軟體#讓客戶做決定|讓客戶做決定]]

[[交付用戶想要的軟體#讓設計指導而不是操縱開發|讓設計指導而不是操縱開發]]

[[交付用戶想要的軟體#合理地使用技術|合理地使用技術]]

[[交付用戶想要的軟體#保持可以發布|保持可以發布]]

[[交付用戶想要的軟體#提早集成頻繁集成|提早集成頻繁集成]]

[[交付用戶想要的軟體#提早實現自動化部署|提早實現自動化部署]]

[[交付用戶想要的軟體#使用演示獲得頻繁反饋|使用演示獲得頻繁反饋]]

[[交付用戶想要的軟體#使用短迭代增量發布|使用短迭代增量發布]]

[[交付用戶想要的軟體#固定價格就意味著背叛承諾|固定價格就意味著背叛承諾]]

🔁 敏捷反饋

[[敏捷反饋#守護天使|守護天使]]

[[敏捷反饋#先用它再實現它|先用它再實現它]]

[[敏捷反饋#不同環境就有不同問題|不同環境就有不同問題]]

[[敏捷反饋#自動驗收測試|自動驗收測試]]

[[敏捷反饋#度量真實的進度|度量真實的進度]]

[[敏捷反饋#傾聽用戶的聲音|傾聽用戶的聲音]]

⌨️ 敏捷編碼

[[敏捷編碼#程式碼要清晰表達意圖|程式碼要清晰表達意圖]]

[[敏捷編碼#用程式碼溝通|用程式碼溝通]]

[[敏捷編碼#動態評估取捨|動態評估取捨]]

[[敏捷編碼#增量式編程|增量式編程]]

[[敏捷編碼#保持簡單|保持簡單]]

[[敏捷編碼#編寫內聚的程式碼|編寫內聚的程式碼]]

[[敏捷編碼#告知不要詢問|告知不要詢問]]

[[敏捷編碼#根據契約進行替換|根據契約進行替換]]

🐞 敏捷調試

[[敏捷調試#記錄問題解決日誌|記錄問題解決日誌]]

[[敏捷調試#警告就是錯誤|警告就是錯誤]]

[[敏捷調試#對問題各個擊破|對問題各個擊破]]

[[敏捷調試#報告所有的異常|報告所有的異常]]

[[敏捷調試#提供有用的錯誤信息|提供有用的錯誤信息]]

🤝 敏捷協作

[[敏捷協作#定期安排會面時間|定期安排會面時間]]

[[敏捷協作#架構師必須寫代碼|架構師必須寫代碼]]

[[敏捷協作#實行代碼集體所有制|實行代碼集體所有制]]

[[敏捷協作#成為指導者|成為指導者]]

[[敏捷協作#允許大家自己想辦法|允許大家自己想辦法]]

[[敏捷協作#準備好後再共享代碼|準備好後再共享代碼]]

[[敏捷協作#做代碼複查|做代碼複查]]

[[敏捷協作#及時通報進展與問題|及時通報進展與問題]]

✨ 核心精神
🧰 即用工具
🧭 態度決定一切（4）
📚 學無止境（5）
📦 交付用戶想要的軟件（9）
🔁 敏捷反饋（6）
⌨️ 敏捷編碼（8）
🐞 敏捷調試（5）
🤝 敏捷協作（8）
Link to original

做法	範例
每天固定時間	每天早上 30 分鐘讀一篇技術文章或一段原始碼
記下陌生術語	在筆記裡維護一份「聽過但不懂」的清單，每週挑一個深入
教別人	把學到的東西寫成內部分享——《45 個習慣》的「對團隊投資」
用在工作上	學一個新工具，就在下一個專案的小地方用它

✗ 對人	✓ 對事
「你又忘了處理錯誤。」	「這個函式在 `ctx` 被取消時會回傳什麼？」
「這寫法太菜了。」	「這裡用 map 會不會比較快？這個 slice 可能有幾千個元素。」
「誰寫的這段？」（在事故中）	「這段程式碼在什麼情況下會拿到空值？」