simplify-code

コードをシンプルにする — 不必要な複雑さを減らす

最良のコードは、書かずに済むコードです。その次に良いのは、誰でも読めるコードです。

基本原則

Complexity is a cost. Every abstraction, every indirection, every clever pattern
adds cognitive load. Simplify ruthlessly unless complexity serves a clear purpose.

---

シンプル化チェックリスト

1. 不必要な抽象化

問題の兆候	シンプル化
処理を委譲するだけのラッパークラス	ラッパーを削除し、内部クラスを直接使う
1種類しか生成しないファクトリー	直接コンストラクターを使う
戦略が1つだけのストラテジーパターン	シンプルな関数に置き換える
実装が1つしかないインターフェース	インターフェースを削除し、クラスを使う
子クラスが1つしかない抽象クラス	子クラスに統合する
値が2つだけの設定オブジェクト	関数パラメーターを使う

2. デッドコード

問題の兆候	対応
未使用のインポート	削除する
到達不能な分岐	削除する（先にテストを確認する）
コメントアウトされたコード	削除する（Git の履歴に残っています）
未使用の変数／関数	削除する
6か月以上前の TODO コメント	削除するか、課題を作成する
リリース済み機能のフィーチャーフラグ	フラグを削除し、コードは残す

3. 深いネスト

// ❌ Before: 4 levels deep
function process(data) {
  if (data) {
    if (data.items) {
      for (const item of data.items) {
        if (item.active) {
          doSomething(item)
        }
      }
    }
  }
}

// ✅ After: Early returns + filter
function process(data) {
  if (!data?.items) return

  data.items
    .filter(item => item.active)
    .forEach(doSomething)
}

4. パラメーターが多すぎる関数

// ❌ Before: 8 parameters
function createUser(name, email, age, role, dept, active, verified, avatar) { }

// ✅ After: Object parameter
function createUser(opts: CreateUserOpts) { }

5. 早すぎる最適化

問題の兆候	シンプル化
100項目未満のカスタムキャッシュ	キャッシュを削除し、まず計測する
コストの低い関数へのメモ化	メモ化を削除する
小さなモジュールの遅延読み込み	直接インポートする
状態が3つの複雑なステートマシン	シンプルな if/else または switch を使う

---

シンプル化の手順

ステップ 1：複雑さを特定する

- Count nesting levels (target: ≤3)
- Count function parameters (target: ≤4)
- Count lines per function (target: ≤30)
- Count abstractions per feature (target: ≤2)
- Check for dead code (target: 0)

ステップ 2：理解を確認する

シンプル化する前に、次の点を理解していることを確認してください。

• コードが何をするか（見た目上の動作ではなく）
• なぜこのように書かれたのか（理由があるかもしれません）
• どのテストが対象としているか（シンプル化でテストを壊してはいけません）

ステップ 3：段階的にシンプル化する

1. Remove dead code first (safest)
2. Flatten nesting with early returns
3. Inline trivial abstractions
4. Merge related functions
5. Simplify data structures

ステップ 4：動作が維持されていることを確認する

npm run test    # All existing tests still pass
npm run build   # Still compiles

---

シンプル化しない場合

状況	複雑さを維持する理由
パフォーマンスが重要なホットパス	最適化は複雑に見えても、必要な場合があります
フレームワーク／ライブラリで必要とされる	外部の制約
パターンが明示的に要求されている	ユーザーがこのアーキテクチャを選択しています
近いうちに拡張が必要になる	抽象化によって、既知の拡張に備えられます

まず確認してください：「このパターンは過剰に設計されているようです。シンプル化すべきですか？それとも、この抽象化には理由がありますか？」