技術債（Technical Debt）

是什麼？

技術債（Technical Debt） 是「用比喻借貸來換取短期開發速度」的概念。這個比喻最早由 Ward Cunningham（Wiki 與 Extreme Programming 的發明者之一）提出。他的原始定義是：

為了趕快交付，我們可以先寫出「不完全正確、但能動」的程式碼，就像借了一筆錢。只要我們之後回頭把它改對（還本金），借貸是健康的；但如果一直不還，利息會壓垮整個專案。

對應到比喻：

• 本金（Principal）：那些不良的設計、混亂的程式碼、走捷徑留下的問題本身。
• 利息（Interest）：因為這些問題還在，導致你日後每一次維護都多花的代價。

身為資深 C# 開發者，你一定遇過這種情況：一個三年前「先這樣，之後再重構」的暫時方案，到今天還在 production 裡，而且每個新功能都要小心翼翼地繞過它。那段「之後」付出的所有額外時間，就是你一直在繳的利息。

技術債的「利息」是什麼

利息是技術債最容易被忽略、卻最致命的部分。它指的是：因為當初的爛設計，團隊在未來持續多付出的成本。 具體會以這些形式出現：

• 改一個小功能要花更久：因為邏輯糾纏、沒有測試保護，動一個地方要看十個地方。
• 更多的 bug：脆弱的設計讓修了 A 又冒出 B，回歸測試成本飆升。
• 更高的上線風險：沒人敢動的程式碼，每次部署都像拆炸彈。
• 新人上手變慢：看不懂、沒文件、命名混亂，教育訓練成本變高。
• 人員流失：長期在高利息的程式碼裡掙扎，工程師會疲乏甚至離職。

// 本金：一段為了趕上線寫死、又沒有抽象的計價邏輯
decimal price = quantity * 199; // 199 是什麼？沒人記得
 
// 利息：三個月後行銷要做「會員 9 折」，你發現這段邏輯
// 被複製貼上散落在 5 個地方，每個都要改、每個都可能漏改、每個都沒測試。
// 這多花的 2 小時 + 上線後漏改一處導致的 bug，就是你正在繳的利息。

Fowler 技術債四象限

Martin Fowler 把技術債依「是否刻意（故意 vs 無意）」與「是否謹慎（謹慎 vs 魯莽）」分成四個象限。這是面試最常被問到的分類，務必理解清楚。

技術債的類型

技術債不只藏在程式碼裡，它散布在整個系統的各個層面：

• 程式碼債（Code Debt）：重複貼上、命名混亂、超長方法、魔術數字、缺乏單一職責。
• 設計／架構債（Design/Architecture Debt）：分層混亂、循環相依、上帝物件（God Object）、邊界不清，導致牽一髮動全身。
• 測試債（Test Debt）：測試覆蓋率不足、被 [Ignore] 掉的測試、只有「快樂路徑」沒有邊界案例。
• 文件債（Documentation Debt）：沒有 README、API 文件過期、設計決策無人記錄。
• 相依套件債（Dependency Debt）：使用過時、已停止維護或有安全漏洞的 NuGet 套件，且不敢升級。
• 基礎設施債（Infrastructure Debt）：手動部署、沒有 CI/CD、伺服器 OS 過舊、環境設定靠口耳相傳。

簡單易懂的 C# 舉例

下面這段程式碼幾乎集滿了各種技術債，是現實專案裡很常見的樣子：

public class OrderService
{
    public void PlaceOrder(string user, int qty)
    {
        // 設計/相依債：連線字串寫死在程式裡，環境一換就爆
        var conn = new SqlConnection("Server=prod-db;User=sa;Password=1234;");
 
        // 程式碼債：魔術數字，299 與 0.95 完全沒有語意
        decimal total = qty * 299 * 0.95m;
 
        // 程式碼債：到處複製貼上的驗證邏輯（這段在 5 個 Service 都有一份）
        if (user == null || user.Length == 0)
            throw new Exception("user error"); // 還丟了不具語意的例外
 
        conn.Open();
        // ... 直接拼字串組 SQL，連 SQL Injection 風險都一起借了
    }
}

public class OrderServiceTests
{
    // 測試債：唯一一個會驗證金額的測試，被 Skip 掉了
    [Ignore("計價邏輯改過，這個測試壞了，先關掉之後再修")]
    [Test]
    public void PlaceOrder_ShouldApplyDiscount() { /* ... */ }
}

<!-- 相依債：三年沒升級、且已知有漏洞的套件，但「不敢升怕壞掉」 -->
<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />

每一行註解標出的，都是一筆正在滾利息的技術債。注意 [Ignore] 那個測試——它把「日後改計價邏輯沒人會發現出錯」的風險也一起借走了。

怎麼管理與償還

技術債本身不可怕，看不見、不還、或一次還太多才可怕。健康的做法是把它變成「看得見、可管理」的東西。

追蹤（讓債務可見）

• 在程式碼裡用 // TODO: 或 // HACK: 標記，並串接到 issue。
• 為每筆值得處理的債開一張 issue／ticket，估出本金（要花多少時間還）。
• 建立技術債看板（Tech Debt Backlog），讓它和功能需求一起被排序、被看見。

償還策略

• 童子軍規則（Boy Scout Rule）：「離開營地時，讓它比你來的時候更乾淨。」每次碰到一段程式碼，就順手把它改好一點點——重新命名一個變數、抽出一個方法、補一個測試。靠日積月累的小清理，避免債務累積。
• 預留還債時間：例如每個衝刺固定撥 10～20% 的產能還債，讓它成為常態而非例外。
• 邊改邊還（Refactor in context）：當你正好要改某個功能時，順道重構它周邊的爛 code——因為你此刻最了解它，也最有理由動它。

常見誤區

實戰補充（Q&A）

Q：技術債一定是壞事嗎？ A：不一定。就像貸款買房可以讓你提早住進去，技術債也能讓你提早上市、提早驗證商業假設。關鍵在於它是「謹慎且故意」的——你清楚知道借了什麼、利息多高、什麼時候還。真正的壞債是「魯莽且無意」：你根本不知道自己在欠債。

Q：什麼時候應該刻意舉債？ A：當「時間的價值」高於「利息」時。例如：搶在競爭對手前推出 MVP、趕一個有截止日的行銷活動、或想先用簡單版本驗證使用者是否真的需要這功能（這時過度設計反而是浪費，呼應 YAGNI）。但前提是你要把這筆債記錄下來、排進 backlog，並在驗證成功後回頭償還。

Q：要怎麼跟主管／PM 溝通技術債？ A：不要說「程式碼很醜」，要用「利息」的商業語言。例如：「這塊債讓我們每個相關需求多花 30% 工時，且上線風險高。花兩天還掉，之後的開發速度能恢復。」把技術問題翻譯成時間與風險，決策者才聽得進去。

理解測驗

重點整理