j5ik2o/okite-ai/intent-based-dedup

重複コードを発見した
    ↓
2つのコードの「目的」は同じか？
    ├─ YES → 字面は同じか？
    │         ├─ YES → 共通化する（標準的DRY）
    │         └─ NO → 実装方式を統一する
    └─ NO → 字面は同じか？
              ├─ YES → ⚠ 共通化禁止（最も危険なケース）
              └─ NO → 何もしない

❌ 異なるドメイン概念に同じユーティリティ関数を使い回す
❌ "たまたま同じ計算式" を共通関数に抽出
❌ 共通化した関数に if (type == A) / else if (type == B) の分岐が増える
❌ 共通関数名が汎用的すぎる（calculate, process, transform等）
❌ 一方の仕様変更時に「もう一方も壊れないか」を心配する
❌ 共通関数のパラメータが増殖し続ける

// ❌ 同じ目的の処理が2箇所に重複
fn report_even_squares(numbers: &[i32]) -> Vec<i32> {
    numbers.iter()
        .filter(|&&x| x % 2 == 0)
        .map(|&x| x * x)
        .collect()
}
 
fn display_even_squares(numbers: &[i32]) -> Vec<i32> {
    numbers.iter()
        .filter(|&&x| x % 2 == 0)
        .map(|&x| x * x)
        .collect()
}
 
// ✅ 共通化: 同じ目的なので1つにまとめる
fn even_squares(numbers: &[i32]) -> Vec<i32> {
    numbers.iter()
        .filter(|&&x| x % 2 == 0)
        .map(|&x| x * x)
        .collect()
}

// パターンA: 関数型アプローチ
fn total_a(values: &[i32]) -> i32 {
    values.iter().fold(0, |acc, &x| acc + x)
}
 
// パターンB: 命令型アプローチ
fn total_b(values: &[i32]) -> i32 {
    let mut sum = 0;
    for &v in values { sum += v; }
    sum
}
 
// ✅ どちらか一方に統一（チーム規約に従う）
fn total(values: &[i32]) -> i32 {
    values.iter().sum()
}

// ケース1: 攻撃力計算（地形倍率を適用）
fn adjusted_attack_points(weapon_points: &[i32]) -> Vec<i32> {
    weapon_points.iter()
        .map(|&x| x * 2)
        .filter(|&x| x % 2 == 0)
        .map(|x| x * x)
        .collect()
}
 
// ケース2: 武器加工費用計算
fn weighted_crafting_costs(amounts: &[i32]) -> Vec<i32> {
    amounts.iter()
        .map(|&x| x * 2)
        .filter(|&x| x % 2 == 0)
        .map(|x| x * x)
        .collect()
}

// ❌ 危険な共通化
fn apply_formula(values: &[i32]) -> Vec<i32> { /* ... */ }
 
let attack = apply_formula(&weapon_points);  // 攻撃力？
let cost = apply_formula(&amounts);          // 費用？
// → 一方を変更すると他方が壊れる