分而治之是人類解決問題的基本手段。普通人與高手之間的差異，很大程度上取決於任務分解的粒度大小。

大師級程式設計師的工作秘笈是任務分解，分解到可以進行的微操作。

為什麼要任務分解#

軟體變更成本會隨著時間和開發階段逐步增加。越早發現問題，修復成本越低。任務分解讓我們：

• 更早發現問題
• 更準確估算時間
• 更容易追蹤進度
• 更少被打斷後迷失

分解到什麼程度#

任務拆小，越小越好。每一步都應該非常容易執行。

這樣做的好處：

• 事前思考：不會造成遺漏
• 抗打斷：被中斷後知道該從哪一步繼續

任務分解的順序#

按照完整實現一個需求的順序安排開發任務，而不是按技術層次（先資料庫、再後端、最後前端）。

先寫思路、需要用到的知識點、API 等，寫出各個小任務，然後對應寫出關鍵程式碼段。最後真正敲程式碼可能只花很少時間。

測試金字塔#

行業中測試組合的最佳實踐：

flowchart TB
    subgraph pyramid [測試金字塔]
        E2E[🔺 E2E 測試<br/>少量]
        INT[🔶 整合測試<br/>適量]
        UNIT[🟩 單元測試<br/>大量]
    end

    E2E --> INT --> UNIT

    style E2E fill:#ffcdd2,stroke:#c62828
    style INT fill:#fff9c4,stroke:#f9a825
    style UNIT fill:#c8e6c9,stroke:#2e7d32

多寫單元測試。單元測試運行快、覆蓋廣、定位問題準確。

測試驅動開發（TDD）#

TDD 的節奏是：紅 → 綠 → 重構

flowchart LR
    R[🔴 紅<br/>寫失敗的測試] --> G[🟢 綠<br/>最少程式碼通過]
    G --> RF[🔵 重構<br/>改善結構]
    RF --> R

    style R fill:#ffcdd2,stroke:#c62828
    style G fill:#c8e6c9,stroke:#2e7d32
    style RF fill:#bbdefb,stroke:#1565c0

1. 紅：先寫一個失敗的測試
2. 綠：寫最少的程式碼讓測試通過
3. 重構：改善程式碼結構，保持測試通過

重構是 TDD 區別於「測試先行」的關鍵。 TDD 帶來的思維改變是：編寫可測的程式碼。

好測試的標準：A-TRIP#

需求管理：艾森豪威爾矩陣#

將事情按照重要和緊急兩個維度劃分：

quadrantChart
    title Eisenhower Matrix
    x-axis "Not Urgent" --> "Urgent"
    y-axis "Not Important" --> "Important"
    quadrant-1 "Do First"
    quadrant-2 "Schedule"
    quadrant-3 "Eliminate"
    quadrant-4 "Delegate"

重要但不緊急的事情應該是我們重點投入精力的地方。許多人把時間都花在緊急但不重要的事情上。

排序是一次性的動作嗎？#

不是。情境一直在變：估了一個月的改造因技術細節暴增成三個月，還值得繼續嗎？舊功能突然每天耗掉一小時維運，要先去長期修復嗎？

沒有「最佳」的個人生產力流程，重點是養成定期重新檢視的習慣：每天早上挑出當日要做的幾項，每週固定花 30 分鐘檢討與重排，每月做一次更大方向的校正。

排序時，優先「直接產生價值」的事。衡量成果時看的是出貨的產品、新增的使用者、推進的業務指標——而不是工時、完成任務數或寫了多少行程式碼。「活動」不等於「產出」。

最小可行產品（MVP）#

「剛剛好」滿足客戶需求的產品。

實踐原則： 用最小的代價找到一條可行的路徑。

技術 Spike#

對不了解的技術任務：

1. 先進行一次技術 Spike（技術探針）學習新技術
2. 丟棄 Spike 過程中開發的原型程式碼
3. 然後再做正式的任務分解

估算：把猜測變成計畫的輸入#

任務分解之後緊接著要做的就是估算。常見的失敗模式是讓「目標」扭曲「估算」——上頭說「三個月內要上線」，於是把四個月的工作硬塞進三個月。正確的方向相反：讓估算去引導商業決策，而不是反過來。

重大專案的延遲，通常不是被龍捲風摧毀的，而是被白蟻啃掉的——無數個被低估的小任務累積成大延遲。

提升估算準確度的做法#

• 拆到夠細：任何超過兩天的估算，就繼續往下拆。長估算是壞驚喜的藏身處。
• 估「實際需要」，而非「希望多久」。
• 把估算當成機率分布：與其說「六週完成」，不如說「50% 機率四週內、90% 機率八週內」。
• 讓真正要動手的人來估，而不是主管或旁觀者。
• 用歷史資料校準：若你過去總是低估 20%，這次估完就乘 1.25。
• 區分「工時」與「日曆時間」：一個月的工程量 ≠ 一個月內完工。日常還有會議、Bug、帶人、回信，真正能投入的工時遠少於每天八小時。一個常用的換算是「1 個理想工程日 ≈ 2 個實際日曆日」。

先做最危險的任務#

我們天生喜歡先做容易、看得見進度的部分，假裝專案按時推進——但風險其實還沒兌現。

動工前先問自己：「這個專案最可怕的部分是什麼？」然後先做那個。

• 特定風險（新技術、新演算法）：先做小規模的端對端原型或效能 benchmark，把估算誤差壓小。
• 整合風險（所有模組接起來的那一刻最容易爆炸）：一開始就先搭好端對端骨架，用 stub 補上未完成的模組，讓整合成本分攤到整個開發過程，而不是全壓在最後。

實戰指南#