程式設計實務

🎯 什麼情境該想到我

當你正想寫一段「很聰明但很難懂」的程式，或方案越滾越複雜時。

⚙️ 怎麼用

先讓它對，再讓它清楚，再讓它快——而且只在必要時才追求快。

1. 預設選最簡單、最清楚的寫法；清楚勝過聰明。
2. 不要過早最佳化：先量測，確定瓶頸再優化，且只優化熱點。
3. 記住：除錯比寫程式更難——寫到極限聰明，就沒餘力除錯它。
4. 通用與自動化優先：能少寫特例、能自動化就別手動。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 「簡單」指認知簡單，不是偷懶少做該做的驗證。

🔗 相關工具

• 工具-管理複雜度 —— 上位準則，簡單清楚是它最直接的操作化版本
• 工具-介面設計原則 —— 落到 API 這一層：露出什麼、藏什麼決定了使用者眼中的簡單程度

🎯 什麼情境該想到我

當你在設計一個模組/函式庫/API 的公開介面，決定「露出什麼、藏什麼」時。

⚙️ 怎麼用（四原則）

1. 隱藏實作（資訊隱藏）：使用者只看到介面，內部可自由改。
2. 簡單：介面小而好用；常見用法要容易，罕見用法才可以複雜。
3. 正交：功能之間彼此獨立、可自由組合，不重疊、不互相牽制。
4. 一致：命名、參數順序、錯誤處理風格全體一致，可預期。

好的介面讓呼叫端「很難用錯」。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 介面一旦公開就難改；上線前多想一輪，寧可先小再擴。

🔗 相關工具

• 工具-管理複雜度、工具-針對介面編程（GoF）、工具-限界上下文（DDD）

🎯 什麼情境該想到我

當你卡在一個 bug、開始亂改亂試、卻毫無進展時。

⚙️ 怎麼用

1. 先讓 bug 可穩定重現：不能重現就先想辦法重現（最小化輸入）。
2. 看線索、做假設：讀錯誤訊息與最近的改動，別急著改。
3. 二分逼近：用 print/log 或註解，把問題範圍一半一半地縮小。
4. 一次只改一個變因，改完驗證，避免製造新 bug。
5. 相信但要驗證：你「確定沒問題」的地方，正是最該檢查的地方。
6. 修好後補一個測試鎖住它，避免復發。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 難重現的 bug 常來自並發/未初始化/邊界；先穩定環境再查。

🔗 相關工具

• 對照 工具-區分修復與掩蓋症狀（先找 root cause）、工具-反過來想