KISS、YAGNI 與避免過度設計

身為資深 C# 開發者，你大概看過（甚至寫過）那種「為了未來彈性」而長出三層 wrapper、滿是介面與泛型、卻只有一個實作的程式碼。這一課直接回答三個問題：KISS / YAGNI 實際上怎麼做到、怎麼知道自己沒過度設計、以及什麼時候該停手。

是什麼？（KISS、YAGNI、DRY 三者關係與張力）

• KISS（Keep It Simple, Stupid）：在能滿足需求的前提下，選最簡單、最好讀的做法。簡單指的是「認知成本低」，不是「程式碼最短」。
• YAGNI（You Aren't Gonna Need It）：不要為「現在還不存在的需求」寫程式。只實作當下被要求、有驗收條件的功能。
• DRY（Don't Repeat Yourself）：同一個「知識／決策」不應該有多份來源。注意它管的是知識重複，不是「長得像的程式碼」重複。

三者的張力在於：DRY 用力過頭會違反 KISS 與 YAGNI。為了消除兩段「剛好長得像」的程式碼，你可能造出一個被迫服務兩種不同情境的抽象，反而更難懂、更難改。

過度設計的徵兆清單

把這份清單當紅旗（red flag）來自我檢查。出現越多項，過度設計的機率越高：

• 為單一實作建介面：IOrderCalculator 只有一個 OrderCalculator，且沒有測試替身或第二實作的明確需求。
• 用不到的設定開關：appsettings.json 裡一堆 EnableXxx、UseYyy，但實際上永遠是同一個值。
• 過早泛型化：Repository<TEntity, TKey, TContext> 但全專案只存一種實體。
• 層層 wrapper：Service 包 Manager、Manager 包 Helper、Helper 包 Provider，每層都只是轉呼叫。
• 為「未來擴充」加抽象：「之後可能會換資料庫／換金流／支援多語系」但需求文件裡根本沒這條。
• 臆測性參數：方法多了 bool isAsync、CancellationToken、options 卻沒有任何呼叫端用到。
• 設計模式堆疊：一個只跑一次的計算，被包成 Factory + Strategy + 泛型 Repository。
• 抽象的命名很空泛：Manager、Processor、Handler、Base、Helper 滿天飛，看名字猜不出職責。

怎麼知道自己沒過度設計

用三個可操作的準則自我審查：

1. 現在需要 vs 未來可能 問自己：「這段抽象／參數／開關，是為了通過目前的驗收條件，還是為了我想像中的未來？」只為未來服務、現在沒有任何呼叫端，就是 YAGNI 違規。

2. Rule of Three（重複三次才抽象）

• 第 1 次：直接寫。
• 第 2 次：出現重複，先忍住，可以複製貼上，但記下來。
• 第 3 次：模式穩定下來，這時才抽象。

兩次重複往往還看不出「真正共通的本質」，太早抽象容易抽錯維度，造出被迫服務多情境的錯誤抽象。

3. 可逆決策（two-way door）vs 不可逆（one-way door）

• two-way door：之後改起來成本低、影響範圍小（例如一個內部方法的實作、變數命名、要不要先抽介面）。→ 快速決定、先做最簡單版，需要再改。
• one-way door：之後很難回頭（例如公開 API 合約、資料庫 schema、對外事件格式、第三方整合協定）。→ 值得多花時間設計與審查。

停止規則（什麼叫「夠好」）

過度設計的另一面，是不知道何時收手。給自己一個明確的「完成」標準，同時滿足以下四點就停手：

1. 通過驗收條件：滿足當前需求與測試，沒有遺漏的 case。
2. 可讀：同組另一位開發者不需要你解釋就能看懂。
3. 可測：能寫出單元測試，依賴可被隔離（這通常是「需不需要介面」的真正判準）。
4. 能改：未來要改時，改動範圍可控、不會牽一髮動全身。

達標就停。不要因為「再加一層會更漂亮」而繼續——那是為審美而非需求工作。

C# 對比範例

需求：給定一張訂單金額，滿千折一百，算出應付金額。 這個需求現在只用一次、規則固定。

過度設計版（Factory + Strategy + 泛型 Repository，全部為「未來」服務）：

public interface IDiscountStrategy
{
    decimal Apply(decimal amount);
}
 
public class ThousandDiscountStrategy : IDiscountStrategy
{
    public decimal Apply(decimal amount)
        => amount >= 1000 ? amount - 100 : amount;
}
 
public interface IDiscountStrategyFactory
{
    IDiscountStrategy Create(string strategyName);
}
 
public class DiscountStrategyFactory : IDiscountStrategyFactory
{
    public IDiscountStrategy Create(string strategyName) => strategyName switch
    {
        "thousand" => new ThousandDiscountStrategy(),
        _ => throw new NotSupportedException(strategyName)
    };
}
 
public interface IRepository<TEntity, TKey>
{
    TEntity GetById(TKey id);
}
 
public class OrderService
{
    private readonly IDiscountStrategyFactory _factory;
    public OrderService(IDiscountStrategyFactory factory) => _factory = factory;
 
    public decimal CalculatePayable(decimal amount)
        => _factory.Create("thousand").Apply(amount);
}

問題：四個型別、兩個介面、一個工廠、一個用不到的泛型 Repository——只為了一條 if。沒有第二種折扣策略、沒有第二種實體，所有「彈性」都是猜測。

簡單直接版（KISS + YAGNI）：

public static class OrderPricing
{
    public static decimal CalculatePayable(decimal amount)
        => amount >= 1000 ? amount - 100 : amount;
}

一個純函式、好讀、好測（OrderPricing.CalculatePayable(1200) 直接斷言）。當哪天真的出現第三種折扣規則（Rule of Three），再回頭抽出 IDiscountStrategy 也完全來得及——因為這是 two-way door。

決策流程

遇到「重複出現」或「有人喊未來要擴充」時，照這個流程決定要不要抽象：

常見誤區

實戰補充：KISS 跟 SOLID 衝突嗎？

Q：既然要 KISS、要 YAGNI，那 SOLID（尤其是 DIP、OCP）不就鼓勵我先加介面、先預留擴充點嗎？兩者矛盾嗎？

A：不矛盾，但有先後。SOLID 是當你已經需要某種彈性時，把它做對的指引；KISS / YAGNI 則回答你現在到底需不需要那種彈性。

• OCP（對擴充開放） 不是要你預先為所有可能的變化開洞，而是當變化「真的反覆發生」時（Rule of Three），用擴充點取代到處改 if。
• DIP（依賴反轉） 的價值在於可測性與替換真實依賴（DB、HTTP、時間）。當依賴需要被隔離測試時就抽介面；若只是個純計算、沒有外部副作用，加介面只是噪音。

實務順序：先用 KISS / YAGNI 寫出最簡單可行版 → 出現真實的變化壓力或測試需求 → 用 SOLID 引導重構。先 SOLID 後需求，往往就變成過度設計。

理解測驗

重點整理