refactoringlisted

# 安全な構造改善 **テストがなければ、それは構造改善ではなく単なる編集である。** 振る舞いが変わっていない ことを示す手段がない書き換えは、この Skill の対象外として扱う。 この工程は**レビューと同じく、実装のあとに必ず通す**。動くコードが出た時点では整理が済んで いないことを前提に置く。対象は書き換えた行だけでなく、**その呼び出し元・呼び出し先と、同じ ファイル・同じモジュールの関連箇所まで**を含む（範囲と例外は [references/code-smells.md](references/code-smells.md) の「手を付ける範囲」）。 ## 最初に決める 2 つのこと ### 1. 機能変更と構造改善を混ぜない 同じ差分に両方を入れると、レビュアーは「意図した振る舞いの変更」と「構造改善の事故」を 区別できない。 ```text ❌ 機能追加と同時に周辺を整理した 1 つのコミット ✅ コミット A: 構造改善（振る舞い不変。既存テストが通る） コミット B: 機能追加（新しいテストが増える） ``` 順序は **構造改善 → 機能変更** を既定とする。先に整理すると機能変更の差分が小さくなる。 ただし整理の必要性が機能変更を通して初め��分かった場合は、機能変更を先に通し、構造改善を 別の差分に切り出してもよい。 ### 2. テストの有無で手順を分ける | 状況 | 進め方 | | --- | --- | | 対象コードに振る舞いを担保するテストがある | 下の「テストがある場合」 | | テストがない・少ない・実装詳細に結合している | 下の「テストが乏しい既存コード」 | 判定は行数ではなく **これから変える経路がテストで通っているか**で行う。カバレッジの 数値ではなく、実際にその関数を通すテス��があるかを確認する。 ## テストがある場合 1. **変更前に既存テストを実行する。** ここで落ちているものがあれば、先に報告する 2. スメルを 1 つ選ぶ（一覧は [references/code-smells.md](references/code-smells.md)） 3. 対応する手法を選ぶ（[references/refactoring-catalog.md](references/refactoring-catalog.md)。 スメル一覧で ★ が付いた手法はカタログに項目がなく、一覧の記述だけで進めてよい）。 分岐・反復・定数を**何にどう置き換えるか**は [references/data-representation.md](references/data-representation.md) で決める 4. **1 手だけ適用する** 5. テストを実行する。落ちたら直前の 1 手を戻す 6. 通ったらコミットする（1 手 = 1 コミットを既定とする） 7. 2 へ戻る 一度に複数のスメルへ手を入れない。落ちたときに原因を切り分けられなくなる。 ## テストが乏しい既存コード 振る舞いを変えないことを示す手段がないため、**先に手段を作る**。 ```mermaid flowchart TD A[構造分析] --> B[現状固定テストを追加] B --> C{現状の振る舞いは<br/>妥当か} C -->|妥当| D[段階的に改善] C -->|不具合を含む| E[不具合として別に扱う]