程式設計師修煉之道

🎯 什麼情境該想到我

當你發現「同一件事在多個地方重複」、改一處就得同步改很多地方（還常漏改）時。

⚙️ 怎麼用

系統中每一項知識，都應該有單一、明確、權威的表述。

1. 辨識重複的「知識」（不只是程式碼，還有邏輯、設定、文件、schema）。
2. 抽取到單一來源：共用函式/模組/常數/設定；讓其他地方引用它。
3. 改動只需改一處 → 消除「漏改造成不一致」的整類 bug。
4. 注意「假重複」：長得像但會各自獨立演變的，別強行合併（否則耦合出問題）。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• DRY 是消除「知識重複」，不是消除「所有相似的字元」；過度 DRY 會造成錯誤耦合。

🔗 相關工具

• 工具-提煉函式 —— 發現重複之後最常用的消除手法，DRY 說「該做」，這張說「怎麼做」
• 工具-程式碼壞味道 —— 反過來用：從壞味道清單（尤其 Duplicated Code）反推哪裡違反了 DRY
• 工具-封裝變化點 —— 互補視角：DRY 消除的是「重複」，這張隔離的是「會變的部分」，兩者常一起出手

🎯 什麼情境該想到我

當你想「先湊合一下、之後再修」，或看到程式碼已經很亂而放任它繼續爛時。

⚙️ 怎麼用

一扇破窗（沒修的爛程式碼、爛設計、爛決策）會招來更多破窗。 一旦「反正已經很亂」的心態蔓延，系統會加速腐爛（軟體熵增）。

1. 看到破窗就修，或至少擋起來：立刻修小問題，或加 TODO/工單追蹤，別放著不管。
2. 維持乾淨的基準線：呼應童子軍規則（工具-註解是必要之惡 所屬的整潔紀律）——離開時比來時更乾淨。
3. 別破第一扇窗：你自己也別為了趕而留下「反正只有一個」的爛攤子。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 緊急時可暫時妥協，但要明確記錄為技術債並排程償還，不能無聲無息地累積。

🔗 相關工具

• 工具-程式碼壞味道 —— 破窗的具體長相，用清單認出「這裡已經破了」
• 工具-小步重構 —— 補窗的手法，一次補一塊比等大重構務實
• 工具-區分修復與掩蓋症狀 —— 品質關卡，用膠帶貼住破窗不算修，只是讓它更難看見

🎯 什麼情境該想到我

當你面對一個大又不確定的系統，不知從何下手、擔心各部分兜不起來時。

⚙️ 怎麼用

「曳光彈」是先射一發能看見軌跡的子彈來校準——在軟體上就是先打通一條最細的端到端路徑（能跑、能驗證），再逐步長肉。

1. 做一個 walking skeleton：從 UI → 邏輯 → DB 的最小可運作骨架，貫穿所有層與整合點。
2. 及早暴露整合風險：端到端先通，最難的「各部分兜不兜得起來」提前驗證。
3. 在骨架上增量長出功能。

曳光彈 ≠ 原型：曳光彈是保留並持續發展的真實骨架；原型是探索用、用完即丟。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 別把「用完即丟的原型」當成正式基礎繼續蓋；兩者目的不同。

🔗 相關工具

• 工具-系統設計思考框架 —— 射曳光彈之前先釐清題目：需求、規模、瓶頸在哪，才知道那條端到端路徑要穿過什麼
• 工具-逐步求精 —— 名字像但不是同一件事：那張（書中稱「反覆精化」）精化的是資料表示法，不是交付順序。「先做能跑的骨架再長肉」是本卡，不是那張
• 工具-架構隨業務規模演進 —— 骨架該做多複雜的判準：先簡單做，等規模真的逼你再上分散式