## Case #2: 手寫 IEnumerator 冗長易錯，改用 yield return

### Problem Statement（問題陳述）
業務場景：團隊需要多個自訂序列（如數字、檔名、資料列），以前以手寫 IEnumerator<T> 類別提供，但伴隨樣板程式碼多（Current、MoveNext、Reset、Dispose、雙介面等），實作與維護負擔大。
技術挑戰：樣板冗長、狀態機邏輯容易出錯。
影響範圍：開發效率、bug 率、團隊共識。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 手寫狀態維護（_current、state）易引入邏輯錯誤。
2. 雙介面（泛型/非泛型）與 Reset/Dispose 寫法繁瑣。
3. 相近迭代器重複開發，無法抽象。

深層原因：
- 架構層面：偏向類別繼承而非方法層級迭代器。
- 技術層面：未利用 yield 的語法糖。
- 流程層面：code review 未要求移除樣板。

### Solution Design（解決方案設計）
解決策略：用 yield return 以方法級別回傳 IEnumerable<T>，由編譯器生成狀態機與介面實作，移除手寫 IEnumerator。

### 實施步驟
1. 盤點與收斂
- 實作細節：列出所有手寫 IEnumerator 類別，找相似邏輯。
- 所需資源：原始碼、統計工具。
- 預估時間：0.5 天。

2. 重構為 iterator method
- 實作細節：用 yield return 重寫；刪除冗餘類別。
- 所需資源：IDE、單元測試。
- 預估時間：1-2 天。

3. 自動化檢查
- 實作細節：建立 Roslyn Analyzer 或 code review checklist。
- 所需資源：CI/CD。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
// 手寫 IEnumerator（摘要）：冗長且易錯
public class EnumSample2 : IEnumerator<int> { /* MoveNext + Current + Reset... */ }

// yield 版本（取代整個類別）
public static IEnumerable<int> Multiples(int start, int end)
{
    for (int i = start; i <= end; i++)
        if (i % 2 == 0 || i % 3 == 0)
            yield return i;
}

## Case #3: 保持消費端不變，替換過濾規則

### Problem Statement（問題陳述）
業務場景：報表產生器需依不同條件輸出數列（如 2 或 3 的倍數、僅偶數、僅 3 的倍數）。要求不改動消費端（foreach 輸出），僅改動產生器。
技術挑戰：保持呼叫介面穩定，替換內部條件。
影響範圍：兼容性、發版風險、測試成本。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 消費端與產生器緊耦合會造成破壞性修改。
2. 過濾與輸出混雜導致難以替換。
3. 無清楚的 API 契約（IEnumerable 輸出）。

深層原因：
- 架構層面：無明確分層（產生/消費）。
- 技術層面：未標準化輸出介面為 IEnumerable。
- 流程層面：需求變更頻繁但未規劃穩定 API。

### Solution Design（解決方案設計）
解決策略：統一定義 IEnumerable<int> 產生器為唯一變更點，消費端只依 foreach。不同條件使用不同 iterator methods 或注入條件委派。

### 實施步驟
1. 定義穩定 API
- 實作細節：public IEnumerable<int> GetSequence(...)
- 所需資源：設計審查。
- 預估時間：0.5 天。

2. 條件實作/注入
- 實作細節：yield 內部替換條件或傳入 Predicate<int>。
- 所需資源：單元測試。
- 預估時間：0.5-1 天。

3. 回歸測試
- 實作細節：消費端不變，驗證輸出集合。
- 所需資源：測試框架。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
public static IEnumerable<int> FilteredRange(int start, int end, Func<int, bool> predicate)
{
    for (int i = start; i <= end; i++)
        if (predicate(i)) yield return i;
}

// 消費端固定
foreach (var n in FilteredRange(1, 100, x => x % 2 == 0 || x % 3 == 0))
    Console.WriteLine(n);

## Case #4: 釐清 yield 的執行模型，避免「一次跑完」的錯誤假設

### Problem Statement（問題陳述）
業務場景：新進同仁以為方法呼叫一定同步完整執行完才 return，對 yield 的「懸掛/恢復」模型不理解，導致在 iterator 中安插副作用（如記錄、IO）而誤判執行時機。
技術挑戰：掌握 yield 編譯後的狀態機語意。
影響範圍：錯誤診斷困難、行為不可預期。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 將 iterator 方法誤當成立即執行的普通方法。
2. 不理解 MoveNext/Current 的協定。
3. 在 iterator 內部加入與時序耦合的副作用。

深層原因：
- 架構層面：缺乏對延遲執行模型的說明與限制。
- 技術層面：不了解編譯器產生的 state machine。
- 流程層面：缺乏針對 yield 的 code review 檢核。

### Solution Design（解決方案設計）
解決策略：示範反組譯後的 MoveNext 狀態機，建立「每次 MoveNext 走一步、yield return 產出一項」的心智模型；規範 iterator 中不得放置錯置副作用。

### 實施步驟
1. 教學與反組譯
- 實作細節：用 ILSpy/Reflector 檢視 MoveNext switch 狀態。
- 所需資源：反編譯工具。
- 預估時間：0.5 天。

2. 編碼規範
- 實作細節：禁止在 iterator 內部做非必要副作用。
- 所需資源：文件、PR 範本。
- 預估時間：0.5 天。

3. 單元測試
- 實作細節：用 MoveNext 驗證產出時機。
- 所需資源：測試框架。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
// 反組譯後（簡化）：MoveNext 以狀態機控制掛起/恢復
private bool MoveNext()
{
    switch (state)
    {
        case 0:
            state = -1;
            i = start;
            goto loop;
        case 1:
            state = -1;
            i++;
        loop:
            if (i <= end) {
                current = i;
                state = 1; // 下次從這裡繼續
                return true;
            }
            break;
    }
    return false;
}

## Case #5: Reset/Dispose 等契約誤用，導入正確 Enumerator 使用法

### Problem Statement（問題陳述）
業務場景：部分代碼嘗試呼叫 enumerator.Reset() 以重用 iterator，結果在 yield 生成的 enumerator 上拋出 NotSupportedException，導致生產環境錯誤。
技術挑戰：正確認知 Enumerator 契約與 yield 生成類別的行為。
影響範圍：可靠性、錯誤處理。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 錯誤期待 Reset 能「回到起點」。
2. 不知道 yield 生成的 enumerator 的 Reset 拋 NotSupportedException。
3. 嘗試在多處重用同一 enumerator 實例。

深層原因：
- 架構層面：未規範迭代器生命週期。
- 技術層面：誤解 IEnumerable.GetEnumerator 的語意。
- 流程層面：缺少例外情境測試。

### Solution Design（解決方案設計）
解決策略：禁止直接呼叫 Reset；若需重新迭代，重新呼叫 iterator method 取得新 enumerator；在 foreach 模式下自然避免誤用。

### 實施步驟
1. 程式碼替換
- 實作細節：移除 Reset，改以重新取得 enumerator。
- 所需資源：重構工具。
- 預估時間：0.5 天。

2. 例外測試
- 實作細節：驗證 Reset 會拋出例外。
- 所需資源：測試框架。
- 預估時間：0.5 天。

3. 文件與教育
- 實作細節：撰寫契約說明。
- 所需資源：團隊文件。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
// 錯誤：不要呼叫 Reset()
using (var e = Multiples(1, 100).GetEnumerator())
{
    while (e.MoveNext()) { /* ... */ }
    // e.Reset(); // NotSupportedException
}

// 正確：重新取得 enumerator
foreach (var n in Multiples(1, 100)) { /* 第一次 */ }
foreach (var n in Multiples(1, 100)) { /* 第二次 */ }

## Case #6: 將 while(e.MoveNext()) 改為 foreach，避免 API 誤用

### Problem Statement（問題陳述）
業務場景：開發者直接操作 IEnumerator，常見 Current/MoveNext 順序誤用或遺漏 Dispose，產生隱晦 bug。希望改為 foreach 簡化。
技術挑戰：替換成本低且行為一致。
影響範圍：穩定性、可讀性。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 手動控制 MoveNext/Current 易出錯。
2. 忽略釋放 enumerator（Dispose）。
3. 不了解 foreach 的語法糖可自動處理。

深層原因：
- 架構層面：缺少高層抽象（foreach）。
- 技術層面：不了解 C# foreach 轉譯。
- 流程層面：沒有程式碼規範。

### Solution Design（解決方案設計）
解決策略：統一用 foreach 操作 IEnumerable，讓編譯器產生正確的 try/finally/Dispose 模式，降低誤用機會。

### 實施步驟
1. 搜尋與替換
- 實作細節：將 while(e.MoveNext()) 迴圈重寫為 foreach。
- 所需資源：IDE、重構工具。
- 預估時間：0.5-1 天。

2. 行為比對
- 實作細節：輸出結果應一致。
- 所需資源：測試。
- 預估時間：0.5 天。

3. 規範落地
- 實作細節：PR 模板加入規定。
- 所需資源：文件。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
// 原始寫法
var e = Multiples(1, 100).GetEnumerator();
while (e.MoveNext()) Console.WriteLine(e.Current);

// 建議寫法
foreach (var n in Multiples(1, 100))
    Console.WriteLine(n);

## Case #7: 迭代器內的條件過濾寫法：do-while vs yield return

### Problem Statement（問題陳述）
業務場景：有人在 MoveNext 裡以 do-while 跳過不符條件的元素（參考原文 EnumSample2），有人在 iterator method 中用 if + yield return。需統一團隊寫法。
技術挑戰：可讀性、行為一致與錯誤率。
影響範圍：維護性、跨人協作。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 多種寫法混用，理解成本高。
2. do-while 狀態控制難度較高。
3. if + yield return 更貼近意圖但不被統一採用。

深層原因：
- 架構層面：未形成一致的 iterator policy。
- 技術層面：忽視語義化的優雅寫法。
- 流程層面：code review 缺乏規範。

### Solution Design（解決方案設計）
解決策略：優先在 iterator method 內使用 if + yield return 的語義化過濾；只有在需要手寫 IEnumerator 時才使用 do-while 控制。

### 實施步驟
1. 規範制定
- 實作細節：文檔化首選寫法。
- 所需資源：團隊共識。
- 預估時間：0.5 天。

2. 範例與範本
- 實作細節：提供可複用模板。
- 所需資源：樣板程式。
- 預估時間：0.5 天。

3. 漸進重構
- 實作細節：把舊 do-while 版本改為 yield。
- 所需資源：重構工具。
- 預估時間：1 天。

**關鍵程式碼/設定**：
```csharp
// 推薦：if + yield return（語義清晰）
public static IEnumerable<int> Numbers(Func<int, bool> pred)
{
    for (int i = 1; i <= 100; i++)
        if (pred(i)) yield return i;
}

// 僅在手寫 IEnumerator 時使用 do-while 控制

## Case #8: 參數化的序列產生（start/end）的正確使用

### Problem Statement（問題陳述）
業務場景：迭代器需要支援動態範圍（start、end），若寫死為 1..100（原文示例有此現象），會造成重用性不足且需要多份近似代碼。
技術挑戰：正確傳遞與使用參數。
影響範圍：重用性、API 一致性。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 迭代器內部沒有使用方法參數。
2. 使用端因範圍不同而重複實作。
3. 測試覆蓋不足未捕捉此問題。

深層原因：
- 架構層面：未定義統一參數化介面。
- 技術層面：忽視方法參數與狀態機關聯。
- 流程層面：缺乏 API 規格測試。

### Solution Design（解決方案設計）
解決策略：以參數控制範圍，避免硬編碼；透過單元測試確保不同參數輸出正確。

### 實施步驟
1. 修正 iterator
- 實作細節：使用 start、end 參數。
- 所需資源：IDE。
- 預估時間：0.25 天。

2. 加入測試
- 實作細節：不同範圍與邊界值。
- 所需資源：測試框架。
- 預估時間：0.5 天。

3. 文件更新
- 實作細節：API 說明與範例。
- 所需資源：文件。
- 預估時間：0.25 天。

**關鍵程式碼/設定**：
```csharp
public static IEnumerable<int> RangeFiltered(int start, int end, Func<int,bool> pred)
{
    for (int i = start; i <= end; i++)
        if (pred(i)) yield return i;
}

## Case #9: 了解編譯器生成的多介面實作，提升互通性

### Problem Statement（問題陳述）
業務場景：需同時支援 IEnumerable 與 IEnumerable<T> 以兼容舊有 API。手寫實作易漏寫非泛型版本，導致在某些 API 下無法遍歷。
技術挑戰：正確同時實作兩個介面。
影響範圍：相容性、整合性。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 忽略非泛型 IEnumerable 的必要性。
2. 不熟悉顯式介面實作。
3. 容易遺漏 Current 的雙版本。

深層原因：
- 架構層面：對 BCL 相容性關注不足。
- 技術層面：手寫介面樣板繁雜。
- 流程層面：缺少介面相容性檢查。

### Solution Design（解決方案設計）
解決策略：使用 yield 讓編譯器自動生成 IEnumerable<T> 與 IEnumerable 的實作；如需手寫，提供範本與檢查清單。

### 實施步驟
1. 範例教學
- 實作細節：展示反組譯出的 IEnumerable 雙實作。
- 所需資源：反編譯工具。
- 預估時間：0.5 天。

2. 規範
- 實作細節：新代碼一律使用 yield。
- 所需資源：文件。
- 預估時間：0.25 天。

3. 檢查
- 實作細節：對舊代碼做介面覆蓋檢查。
- 所需資源：分析工具。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
// yield 自動生成雙介面：IEnumerable<int> 與 IEnumerable
public static IEnumerable<int> Seq() { yield return 1; }

## Case #10: 由 foreach 與 yield 保障執行緒安全的使用模式

### Problem Statement（問題陳述）
業務場景：開發者嘗試在多執行緒間重用同一 enumerator，導致不一致結果。反組譯顯示編譯器以 Thread.ManagedThreadId 決定是否重用 enumerator 實例。
技術挑戰：正確認知 enumerator 與執行緒的關係。
影響範圍：並行錯誤、資料競態。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 嘗試在多執行緒重用同一 enumerator。
2. 不理解 GetEnumerator 的邏輯可能回傳新實例。
3. 不知道 foreach 自然隔離 enumerator 實例。

深層原因：
- 架構層面：未規劃並行讀取策略。
- 技術層面：不了解生成代碼中的 thread-id 檢查。
- 流程層面：缺乏並行測試。

### Solution Design（解決方案設計）
解決策略：每個執行緒各自呼叫 iterator 方法取得新 enumerator；避免共享 enumerator 實例；以 foreach 迴圈確保隔離。

### 實施步驟
1. 模式規範
- 實作細節：禁止跨執行緒分享 enumerator。
- 所需資源：文件。
- 預估時間：0.25 天。

2. 重構
- 實作細節：改為各自呼叫 IEnumerable 方法。
- 所需資源：IDE。
- 預估時間：0.5 天。

3. 並行測試
- 實作細節：多執行緒 foreach 驗證。
- 所需資源：測試框架。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
// 每個執行緒各自使用 foreach（各自取得 enumerator）
Parallel.For(0, 4, _ =>
{
    foreach (var n in Multiples(1, 100))
        ; // do work
});

## Case #11: 以 yield 回應「大段樣板代碼」的治理

### Problem Statement（問題陳述）
業務場景：專案中存在多個類似的 IEnumerator 類別，僅差在條件與範圍，造成維護困難與 bug 機率上升。
技術挑戰：刪除樣板、統一方式。
影響範圍：維護成本、缺陷率。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 大量重複的 Current/MoveNext/Reset 程式。
2. 輕微變化導致多份拷貝。
3. 無共通產生器方法。

深層原因：
- 架構層面：未以方法級別抽象序列。
- 技術層面：未採用 yield 的語法糖。
- 流程層面：缺少去重目標。

### Solution Design（解決方案設計）
解決策略：建立統一的 iterator method 模板（含 predicate 與範圍），將所有變體收斂為參數與委派。

### 實施步驟
1. 模板設計
- 實作細節：Range + Predicate。
- 所需資源：設計評審。
- 預估時間：0.5 天。

2. 集中重構
- 實作細節：以模板替換各自 enumerator。
- 所需資源：IDE、測試。
- 預估時間：2-3 天。

3. 靜態檢查
- 實作細節：阻擋新增手寫 enumerator。
- 所需資源：Analyzer。
- 預估時間：1 天。

**關鍵程式碼/設定**：
```csharp
public static IEnumerable<T> Where<T>(IEnumerable<T> src, Func<T,bool> pred)
{
    foreach (var x in src) if (pred(x)) yield return x;
}
// 統一使用此模板，而非各自實作 IEnumerator

## Case #12: 以 yield 提升教學與溝通：從迴圈直覺到迭代器

### Problem Statement（問題陳述）
業務場景：新進工程師對 Iterator Pattern 抗拒，僅會寫 loop。需要一種方式讓他們以「像 loop 一樣」的直覺寫出迭代器。
技術挑戰：降低心智負擔。
影響範圍：學習曲線、培訓成本。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 手寫 state machine 不易理解。
2. loop 與 iterator 的語義落差大。
3. 缺少對映示例。

深層原因：
- 架構層面：無統一教學套路。
- 技術層面：未強調 yield 的「語法糖」本質。
- 流程層面：入職培訓不足。

### Solution Design（解決方案設計）
解決策略：以「把 loop 放到 iterator method」為切入點，讓編譯器自動轉譯；搭配反組譯展示一一對應。

### 實施步驟
1. Loop → Yield 對映課
- 實作細節：同題雙寫（loop vs yield）。
- 所需資源：教學範本。
- 預估時間：0.5 天。

2. 反組譯對照
- 實作細節：展示 MoveNext 對映關係。
- 所需資源：ILSpy。
- 預估時間：0.5 天。

3. 練習與回饋
- 實作細節：小練習 + code review。
- 所需資源：導師。
- 預估時間：1 天。

**關鍵程式碼/設定**：
```csharp
// Loop 思維不變，只是把輸出改為 yield return
for (int i = 1; i <= 100; i++)
    if (i % 2 == 0 || i % 3 == 0)
        yield return i;

## Case #13: 用 yield 取得「魚與熊掌」：結合優雅與模式正確性

### Problem Statement（問題陳述）
業務場景：既想保留 loop 的直覺與簡潔，又希望遵循 Iterator Pattern 以獲得結構化與可維護性。如何兼得？
技術挑戰：語法表達與設計模式的一致性。
影響範圍：架構一致性、團隊共識。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. loop 與 iterator 二選一的錯誤觀念。
2. 手寫 iterator 太繁瑣。
3. 忽視 yield 的價值。

深層原因：
- 架構層面：設計模式落地缺口。
- 技術層面：對語法糖缺乏信心。
- 流程層面：缺乏統一指引。

### Solution Design（解決方案設計）
解決策略：以 yield 作為 loop 與 iterator 的橋樑，保留 loop 的「看起來像」與 iterator 的「用起來對」。

### 實施步驟
1. 指南
- 實作細節：推薦 iterator method + foreach。
- 所需資源：文件。
- 預估時間：0.25 天。

2. 範例庫
- 實作細節：常見迭代器模板。
- 所需資源：範例專案。
- 預估時間：0.5 天。

3. 檢視點
- 實作細節：Code review 檢核「是否可 yield」。
- 所需資源：PR 模板。
- 預估時間：0.25 天。

**關鍵程式碼/設定**：
```csharp
public static IEnumerable<int> YieldReturnSample3(int start, int end)
{
    for (int current = start; current <= end; current++)
        if (current % 2 == 0 || current % 3 == 0)
            yield return current;
}
// 消費端：foreach（Iterator Pattern）

## Case #14: 以反組譯輔助除錯 yield 迭代器

### Problem Statement（問題陳述）
業務場景：在 iterator 中發生邏輯錯誤（少輸出、重複輸出），難以單步理解執行流程。需透過反組譯理解狀態轉移。
技術挑戰：對生成代碼的閱讀與對照。
影響範圍：除錯效率、正確性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 不知道該怎麼觀察 state 與 Current。
2. 不了解 GetEnumerator 與 MoveNext 的互動。
3. 缺少工具鏈支持。

深層原因：
- 架構層面：未將反組譯納入除錯流程。
- 技術層面：狀態機觀念薄弱。
- 流程層面：缺乏除錯 SOP。

### Solution Design（解決方案設計）
解決策略：建立「反組譯 + 斷點移動」的除錯 SOP，並在 MoveNext 的 case 分支上設斷點觀察 state 變化與 Current 賦值時機。

### 實施步驟
1. 反組譯
- 實作細節：取得 d__ 類別，檢視 MoveNext。
- 所需資源：ILSpy/Reflector。
- 預估時間：0.5 天。

2. 斷點策略
- 實作細節：在 MoveNext 的 case 與 yield 點設斷點。
- 所需資源：IDE。
- 預估時間：0.25 天。

3. 驗證
- 實作細節：確保每個 yield 點都能命中。
- 所需資源：測試。
- 預估時間：0.25 天。

**關鍵程式碼/設定**：
```csharp
// 在反組譯出的 MoveNext 中觀察：
// - state 何時從 0 -> 1 -> -1
// - current 何時被設定
// - case 分流的對應源碼位置

## Case #15: 以 yield 將副作用外移，提升可測試性

### Problem Statement（問題陳述）
業務場景：原本在 loop 中直接 Console.WriteLine，造成單元測試困難。希望把「輸出」外移，只測「序列正確性」。
技術挑戰：將副作用與純邏輯分離。
影響範圍：可測試性、持續整合。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 在產生過程中混入輸出副作用。
2. 難以對輸出做斷言。
3. 無法重複測試不同條件。

深層原因：
- 架構層面：未分離 Query（產生）與 Command（輸出）。
- 技術層面：缺少可列舉的中介結果。
- 流程層面：測試導向不足。

### Solution Design（解決方案設計）
解決策略：以 yield 只產生數列，由消費端決定輸出；單元測試對 IEnumerable 做斷言，端到端測試覆蓋輸出。

### 實施步驟
1. 抽離輸出
- 實作細節：iterator method 只 yield，不 Console.WriteLine。
- 所需資源：IDE。
- 預估時間：0.25 天。

2. 單元測試
- 實作細節：ToArray() 與預期比對。
- 所需資源：測試框架。
- 預估時間：0.5 天。

3. 端到端
- 實作細節：整合輸出層測試。
- 所需資源：測試框架。
- 預估時間：0.5 天。

**關鍵程式碼/設定**：
```csharp
// 產生器
public static IEnumerable<int> Multiples2Or3(int start, int end) { /* yield ... */ }

// 測試（舉例）
Assert.Equal(new[]{2,3,4,6}, Multiples2Or3(1,6).ToArray());

## Case #16: 以迭代器方法逐步擴展功能，避免破壞性修改

### Problem Statement（問題陳述）
業務場景：需求持續增加（如新增「5 的倍數」或「排除 7 的倍數」），希望在不改動現有消費端與最小改動產生器的前提下，快速擴展。
技術挑戰：擴展能力與回溯相容。
影響範圍：版本管理、穩定性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 單一方法硬編碼規則。
2. 缺乏擴展點（參數/委派）。
3. 消費端直接依賴具體實作。

深層原因：
- 架構層面：未設計擴展策略。
- 技術層面：條件不可配置。
- 流程層面：缺少版本演進計畫。

### Solution Design（解決方案設計）
解決策略：以 iterator + 可組合的 predicate 設計，透過方法多載或新增方法提供新條件，保留原方法以兼容。

### 實施步驟
1. Predicate 設計
- 實作細節：傳入 Func<int,bool> 或多個條件。
- 所需資源：設計審查。
- 預估時間：0.5 天。

2. 兼容策略
- 實作細節：保留舊 API，新增新 API。
- 所需資源：版本文件。
- 預估時間：0.5 天。

3. 測試
- 實作細節：對新舊條件做交叉測試。
- 所需資源：測試框架。
- 預估時間：1 天。

**關鍵程式碼/設定**：
```csharp
public static IEnumerable<int> RangeWhere(int s, int e, params Func<int,bool>[] preds)
{
    for (int i = s; i <= e; i++)
        if (preds.Any(p => p(i))) yield return i;
}

// 新需求：2 或 3 或 5 的倍數
foreach (var n in RangeWhere(1, 100, x => x%2==0, x=>x%3==0, x=>x%5==0)) { /* ... */ }