ynitto code-simplifier
変更されたコードを再利用性・品質・効率の観点で分析し、問題を直接修正する。
原則
- 動作を変えない — リファクタリングは振る舞いを保つ。バグ修正や機能追加は行わない
- 変更点に集中する — diff がある部分を中心に、スコープを広げすぎない
- 小さく確実に — 一度に一つの変更、テストが通ったらコミットする
- 説明してから修正する — 何をなぜ変えるかを一言添えてから修正する
スコープ境界
| 対象 | 可否 |
|---|---|
| 内部実装の整理・分割・命名改善 | ✅ する |
| 公開 API のシグネチャ変更 | ⚠️ ユーザー承認を得てから行う |
| バグ修正・機能追加 | ❌ しない（別タスクにする） |
| テスト未整備のコードへの大規模変更 | ❌ しない（先にテストを追加する） |
ファストパス（単純な修正）
以下に該当する場合はワークフローを省略し、直接実施してサマリーを出す:
- 変数・関数の改名のみ
- コメントアウトされたコードの削除
- マジックナンバーの定数化
- 明らかに使われていないコードの削除
該当しない場合は以下のワークフローを使う。
ワークフロー
Step 1: 対象コードを特定する
- ユーザーが対象ファイル・範囲を指定している場合はそれを使う
- 指定がない場合は
git diff --name-only HEADで変更ファイルを確認する - 対象ファイルを読んで全体像と既存のテストを把握する
- テストがない場合はリファクタリング前にテスト追加を提案し、ユーザーの承認を得てから Step 2 へ進む
Step 2: 3つの観点で分析する
再利用性（Reuse）
- 重複したロジック・コードブロックがある → 関数・定数・ユーティリティに抽出する
- 同じ処理が複数箇所に散在している → 共通化できるか判断する
- 既存のユーティリティ・ライブラリで代替できる処理がある
品質（Quality）
- 変数名・関数名が意図を反映していない → 改名する
- 関数が複数の責務を持っている（目安: 50行超） → 分割する
- マジックナンバー・ハードコード値がある → 定数化する
- 深いネスト・複雑な条件分岐がある → 早期リターンやガード節で平坦化する
- クラスが肥大化している（神クラス） → 単一責務原則で分割する
- 関数のパラメータが多い（5個以上） → パラメータオブジェクトに変換する
効率（Efficiency）
- 不要な計算・変数・処理がある → 削除する
- ループ内で毎回同じ計算をしている → ループ外に移動する
- 冗長な条件式・型変換がある → 簡潔な表現に置き換える
- 不要な中間変数がある → インライン化する
手法のコード例は references/techniques.md を参照。
Step 3: 修正の優先順位を決める
| 優先度 | 基準 |
|---|---|
| 高 | 50行超の関数・深いネスト・重複コード（理解・変更を直接阻害する） |
| 中 | 神クラス・関数分割・命名改善・定数化 |
| 低 | スタイルの統一、微細なリファクタリング |
スコープを守る: 変更範囲に関連するコードのみを修正する。複数箇所の修正が必要な場合は計画を説明してからユーザーに確認を取る。公開 API の変更を含む場合は必ず明示する。
Step 4: コードを修正する
各変更のサイクル:
テスト実行（緑を確認）→ 1つの変更を実施 → テスト実行 → 全テスト通過後にコミット
- 修正内容を1行で説明してから実施する（例: 「重複した検証ロジックを
validateInput関数に抽出します」） - 一度に複数の問題を修正しない
- テストが通らない場合はすぐに差し戻してから原因を調査する
Step 5: 修正内容をサマリーする
## code-simplifier 結果
### 実施した修正
- [修正内容]: <何をどう変えたか>
### 修正しなかった点（該当あれば）
- <修正を見送った理由>
チェックリスト（完了確認）
- 全テストがリファクタリング前後で通っている
- 公開 API を変更した場合はユーザーの承認を得た
- 機能追加・バグ修正をリファクタリングと混在させていない