reducing-entropy

降低熵值

越多程式碼會產生越多程式碼。熵值不斷累積。此技能傾向於最小的程式碼庫。

核心問題：「程式碼庫之後會是什麼樣子？」

開始之前

從 references/ 載入至少一個思維模式

1. 列出參考目錄中的檔案
2. 閱讀 frontmatter 描述以選擇適用的思維模式
3. 載入至少一個
4. 說明你載入了哪個及其核心原則

在完成此步驟之前，請勿繼續。

目標

目標是最終程式碼庫中的總程式碼更少——而不是現在要寫的程式碼更少。

• 寫 50 行但刪除 200 行 = 淨收益
• 保留 14 個函式以避免寫 2 個 = 淨損失
• 「不變動」不是目標。程式碼更少才是目標。

衡量最終狀態，而非努力程度。

三個問題

1. 解決這個問題的最小程式碼庫是什麼？

不是「最小的變更」是什麼——而是最小的結果是什麼。

• 這能否用 2 個函式取代 14 個？
• 這能否用 0 個函式（刪除該功能）？
• 如果我們這樣做，可以刪除什麼？

2. 提議的變更是否導致總程式碼減少？

計算變更前後的行數。如果之後 > 之前，則拒絕它。

• 「組織更好」但程式碼更多 = 更多熵值
• 「更靈活」但程式碼更多 = 更多熵值
• 「更乾淨的分離」但程式碼更多 = 更多熵值

3. 我們可以刪除什麼？

每次變更都是刪除的機會。問：

• 這會讓什麼變得過時？
• 什麼只是因為我們要取代的東西而存在？
• 我們最多能移除什麼？

紅旗

• 「保留現有內容」 - 現狀偏誤。問題是總程式碼，而非變動量。
• 「這增加了靈活性」 - 為了什麼的靈活性？YAGNI。
• 「更好的關注點分離」 - 更多檔案/函式 = 更多程式碼。分離不是免費的。
• 「型別安全」 - 值得多少行？有時執行時期檢查用更少的程式碼就能贏。
• 「更容易理解」 - 14 件事不比 2 件事容易。

何時不適用

• 程式碼庫對其功能來說已經是最小化
• 你處於有強烈慣例的框架中（不要對抗它）
• 法規/合規要求強制特定結構

參考思維模式

請參閱 references/ 以獲得哲學基礎。

若要新增思維模式，請參閱 adding-reference-mindsets.md。

---

傾向刪除。衡量最終狀態。