程式設計師的職業素養 The Clean Coder

📌 30 秒摘要（Layer 3）

程式碼整潔之道 談「怎麼把 code 寫乾淨」，這本談「怎麼當一個乾淨的專業人」。核心是對自己的產出負責：敢專業地說不、用承諾語言（我會…）而非模糊搪塞、把估算當成機率分佈而非拍胸脯保證、靠**紀律（TDD、練習）**維持品質，並管理好自己的時間、壓力與協作。

🗺 心智圖（Canvas）

程式設計師的職業素養

程式設計師的職業素養

The Clean Coder

🎖 專業＝負責

對品質、對承諾、對錯誤負責

不確定就說不確定 別用模糊搪塞掩飾

🙅 說不與說是

工具-專業地說不與承諾

🎯 什麼情境該想到我

當你被要求「一定要在不可能的時程內做完」，或者面對不合理的要求卻不敢拒絕、只能說「我試試看」的時候。

出處：Robert C. Martin《程式設計師的職業素養》（The Clean Coder）第 2 章「說不」與第 3 章「說是」（站內為掃描版 PDF，引文依 OCR 核對，保留原書簡體字）。

⚙️ 怎麼用

說「不」是盡職，不是不合作（第 2 章）

原書的觀點是：經理和程式設計師是對抗角色，而這對雙方都有利。

「每位经理都承担着工作职责……其中一部分的工作职责，便是要竭尽所能追求和捍卫他们设定的目标。」程式設計師也一樣。

「你的经理要求你在明天之前完成登录页面……如果你明知第二天之前不可能完成登录页面，嘴上却说”好的，我会试试的”，那么便是你失职了。这时候，唯一的尽职方式便是说”不，这不可能”。」

「可能的最好结果，是你和你的经理共同追求的目标。最关键的是要找到那个共同目标，而这往往有赖于协商。」

沒有「試試看」這回事

原書的分析：「尝试」的意思是「付出额外的精力」。

• 「许诺”尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。」
• 「只要你许诺自己会去”尝试”，你其实是在承诺你会确保成功。这样，压力就要由你自己来扛了。」
• 「如果承诺尝试，你其实也在承诺将改变自己原来的方案……新方案是什么？」

原書的例子：經理 Mike 施壓，工程師 Paula 回答「好吧，我們會盡量試試」——Mike 把它當成「好的，沒問題」。

說「是」：承諾的三個步驟（第 3 章，Roy Osherove 撰寫）

「口头上说。心里认真。付诸行动。」

缺乏承諾的用語：

• 需要／應當：「我們要把這活做完。」「有人應當負責去推動這件事。」
• 希望／但願：「希望明天我能完成這個任務。」
• 讓我們（而不是「讓我」）：「讓我們把這事做完。」

原書說，這些說法的共同點是：說話的人「要么显得事情不在”我”的掌控范围内，要么不愿意承担个人责任」。

真正的承諾：「我将在……之前……」——例如「我將在星期二之前完成這個任務」。它是對自己將做的事的清楚陳述，而且有期限。

目標取決於別人時：承諾行動，不承諾結果

「你只能承诺自己能完全掌控的事。」你無法承諾模組能和另一個團隊的系統無縫整合，但可以承諾：

• 和基礎設施組的同事坐下來，花一小時釐清模組間的依賴。
• 建立一個介面，把對其他團隊的依賴抽象出來。
• 本週內至少和負責建置的同事碰頭三次。
• 寫自己的建置腳本做整合測試。

做不到時：越早說越好

「如果你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越好，越早越好。」——越早發出預警，團隊越有機會調整優先順序、找人結對、或改用另一個承諾代替。

在工作中的樣子

情境	✗	✓
不可能的時程	「我盡量試試看。」	「兩週內做不完全部。我可以在兩週內交付登入和註冊，付款流程需要再兩週。」
可以做到	「應該可以吧。」	「我會在週四下班前送出 PR。」
依賴其他團隊	「我保證下週整合完成。」	「我會在週二前跟 API 團隊確認介面，週三前完成我這邊的模擬測試。」
發現會延遲	等到截止日才說	一發現就說，同時提出選項

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

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

• 說「不」要附上選項：原書強調要協商、找到共同目標，而不是單純拒絕。
• 說「是」卻做不到，比一開始說「不」更傷信任。
• 有些審閱者不同意「對抗角色」的說法：原書自己提到，一位審閱者很討厭這一章，說他的團隊從未有過對抗關係。作者的回應是，要做出艱難決定時，對抗角色間的衝突反而最有利。

🔗 相關工具

• 工具-估算的藝術 —— 同一本書：說「不」的底氣來自誠實的估算
• 及時通報進展與問題 —— 《45 個習慣》：不要等別人來問
• 固定價格就意味著背叛承諾 —— 《45 個習慣》：時程承諾的另一面
• 工具-徹底誠實 —— 答應做不到的事，本質上是不誠實

專業人敢對不合理要求說「不」

承諾語言：我會在 X 前完成 Y

📊 估算

工具-估算的藝術

🎯 什麼情境該想到我

當你被問「這個功能要做多久？」，卻不知道怎麼給一個誠實又不害到自己的答案時。

⚙️ 怎麼用

1. 估算是機率分佈，不是承諾：先講清楚「估算 ≠ 保證」，把不確定性攤開講。
2. 三點估算（PERT）：給樂觀(O)、最可能(M)、悲觀(P) 三個值，期望值 ≈ (O + 4M + P) / 6，並算出範圍。
3. 拆小再估：大任務拆成小塊分別估，加總比整體拍腦袋準。
4. 用範圍/信心度溝通：「大約 5–8 天，八成把握」比單一數字誠實。
5. 承諾與估算分開：估算是你的最佳判斷；承諾是你願意負責兌現的（見 工具-專業地說不與承諾）。

★ PERT 的數學：期望值與標準差

三點估算不只算期望值，還算不確定性的大小：

$\mu =\frac{O+4M+P}{6},\sigma =\frac{P-O}{6}$

例：一個任務樂觀 2 天、最可能 3 天、悲觀 10 天。

• $\mu =(2+12+10)/6=4$ 天
• $\sigma =(10-2)/6\approx 1.33$ 天

注意期望值（4 天）比最可能值（3 天）大——因為悲觀的尾巴很長。這正是「最可能的時間」不該拿來當承諾的原因：軟體任務的延遲分布是右偏的，出錯時多花的時間遠多於順利時省下的時間。

★ 多個任務加總：不確定性會互相抵銷

幾個互相獨立的任務加總時：

• 期望值直接相加：${\mu }_{\text{總}}=\sum {\mu }_i$
• 變異數相加（不是標準差）：${\sigma }_{\text{總}}=\sqrt{\sum {\sigma }_i^2}$

例：三個任務，每個 μ = 4 天、σ = 1.33 天。

• 總期望 = 12 天
• 總標準差 = $\sqrt{3\times 1.33^2}\approx 2.3$ 天（而不是 3 × 1.33 = 4 天）

所以「拆小再估」有數學上的理由：拆得越細，整體的相對不確定性越小（大數法則）。但前提是任務真的互相獨立——如果它們共用同一個風險（例如都依賴一個還沒釐清的 API），不確定性不會抵銷。

★ 用機率溝通，而不是單一數字

假設總時間近似常態分布：

說法	計算	例（μ = 12、σ = 2.3）
「一半機會能完成」	μ	12 天
「八成把握」	μ + 0.84σ	約 14 天
「九成五把握」	μ + 1.65σ	約 16 天

對方要承諾日期時，給「九成把握是 15 天」比「12 天」誠實得多——後者只有一半的機會做到。

★ 團隊估算的方法

方法	做法	解決什麼問題
寬頻德菲法（Wideband Delphi）	每人各自估，再公開、討論差異、再估一輪，直到收斂	避免被第一個開口的人或資深者錨定
規劃撲克	德菲法的快速版：同時亮牌，差異大的兩人說明理由	同上，而且快
親和估算	不估數字，先把任務依相對大小排序，再分組	人對「比較」比對「絕對數字」準

最有價值的是差異本身：一個人估 2 天、另一個估 10 天，通常代表兩人對任務的理解不同——討論出來的往往是被遺漏的需求或風險。

★ 校準：拿過去的資料修正

記錄每個任務的估算與實際時間。一段時間後算出實際 ÷ 估算的比例：

• 比例穩定在 1.5 → 你系統性地低估 50%，之後的估算直接乘 1.5。
• 比例變異很大 → 問題不是偏差，而是任務拆得不夠細、或需求不穩定。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 被逼給「一個數字」時，別把樂觀估算當承諾——那是延遲與加班的起點。

🔗 相關工具

• 工具-專業地說不與承諾、工具-時間複雜度分析（成本估算的另一面）

估算是機率分佈，不是拍胸脯保證

三點估算：樂觀／正常／悲觀 誠實溝通不確定性

🥋 紀律與練習

TDD：用測試驅動維持品質

持續練習：程式道場 kata

疲累或趕工時，不犧牲品質

⏳ 時間與壓力管理

學會拒絕加班陷阱

避免進入「泥沼」 察覺並及早脫身

Link to original

🧰 這本書給我的工具

• 工具-專業地說不與承諾 — 被要求做不到的事、被壓時程時
• 工具-估算的藝術 — 被要求「這要多久」時

✨ 關鍵重點（Layer 1–2）

• 專業＝負責：對品質、對承諾、對錯誤負責；不確定就說不確定。
• 說不與說是：專業人敢對不合理要求說「不」，答應時用承諾語言（我會在 X 前完成 Y）。
• 估算：估算是機率分佈不是保證；用三點估算（樂觀/正常/悲觀）誠實溝通不確定性。
• 紀律：TDD、持續練習（如程式道場 kata）、不在疲累/趕工時犧牲品質。
• 管理壓力與時間：學會拒絕加班陷阱、避免進入「泥沼」。

💬 金句原文（Layer 0）

• 「專業人士會說『不』——並且用『是』來兌現承諾。」

🔗 相關

• 技術面見 程式碼整潔之道；工匠心態見 程式設計師修煉之道；紀律見 測試驅動開發