リファクタリングパターンフレームワーク

既存コードの内部構造を改善する一方で、その観察可能な動作は変えない規律あるアプローチ。コードレビュー時、技術的負債の削減時、または新機能用のコード準備時にこれらの名前付き変換を適用します。すべてのリファクタリングは同じループに従います。テストが通ることを確認し、1つの小さな構造的変更を適用し、テストがまだ通ることを確認します。

コアプリンシパル

リファクタリングは書き直しではなく、テストに支えられた小さな動作保存変換のシーケンスです。 コードが「何をするか」は決して変わりません。コードの「整理方法」を変えるのです。小さな検証済みステップを踏む規律があるからこそ、リファクタリングは安全なのです。ビッグバン的な書き直しが失敗するのは、構造的変更と動作的変更を組み合わせるため、何が壊れたのかわからなくなるからです。

基盤: 悪いコードは人格的欠陥ではなく、時間圧力下で機能を提供する自然な結果です。コードスメルは構造が劣化したという客観的な信号です。名前付きリファクタリングは各スメルを修正するための実証済みの機械的レシピです。スメルカタログは「どこを見るか」を教え、リファクタリングカタログは「何をするか」を教えます。

スコア評価

ゴール: 10/10。 コードのレビューまたはリファクタリング時に、以下の原則への準拠に基づいて構造的品質を0～10で評価します。10/10とは、明らかなスメルが残されず、各関数が1つのことを行い、名前が意図を明かし、重複が排除され、リファクタリング済みパスをテストスイートが網羅していることを意味します。常に現在のスコアと10/10に到達するために必要な具体的なリファクタリングを提供してください。

リファクタリングパターンフレームワーク

コード構造を体系的に改善するための6つの焦点領域:

1. トリガーとしてのコードスメル

コアコンセプト: コードスメルは、より深い構造的問題の表面的な指標です。バグではなく(コードは機能しています)、設計がコードを理解、拡張、または保守しにくくしていることを示しています。各スメルは、それを修正する1つ以上の名前付きリファクタリングにマップされます。

なぜ機能するか: スメルの共通語彙がないと、コードレビューは主観的な「これは好きじゃない」に陥ります。名前付きスメルはチームに客観的な基準を与えます。「これはFeature Envy(機能への嫉妬)です。このメソッドは別のクラスの6つのフィールドを使用し、自分のものは1つだけです。」名前が直接修正を指し示します。

重要な洞察:

• スメルは5つのファミリーに分類されます: Bloaters、Object-Orientation Abusers、Change Preventers、Dispensables、Couplers
• Long Methodが最も一般的なスメルであり、ほとんどのリファクタリングのゲートウェイです
• Duplicate Codeは保守コストの最大の推進要因です
• メソッドが「何をするか」説明するためにコメントが必要な場合、それはスメルです。代わりにブロックを抽出して名前を付けます
• Shotgun Surgery(1つの変更で多くのクラスの編集が必要)とDivergent Change(1つのクラスが多くの理由で変更される)は対立していますが、どちらも責務の誤配置を示しています
• Primitive Obsession(生の文字列、int、配列を使用し、小さなドメインオブジェクトを使わない)はコードベース全体でエラーと重複を引き起こします

コード適用:

文脈	パターン	例
メソッド > 10行	Extract Method	ループボディをcalculateLineTotal()に引き出す
クラス > 200行	Extract Class	shipping logicをShippingCalculatorに移動
型コードのswitch	Replace Conditional with Polymorphism	各注文タイプのサブクラスを作成
複数のメソッドが同じパラムを使用	Introduce Parameter Object	startDate, endDateをDateRangeにグループ化
メソッドが別のオブジェクトのデータを使用	Move Method	calculateDiscount()をCustomerクラスに移動
コピー・ペーストされたロジック	Extract Method + Pull Up Method	共通メソッドまたはベースクラス経由で共有

参照: references/smell-catalog.md

2. メソッドの構成

コアコンセプト: ほとんどのリファクタリングはここから始まります。長いメソッドは、よく名前が付けられた小さな部分に分割されます。抽出された各部分は1つのことを行い、その名前はそのことが何であるかを説明する必要があります。ゴールは散文のように読めるメソッドです。各委任先がはっきり名前を付けられたヘルパーへの高レベルのステップのシーケンスです。

なぜ機能するか: 意図を明かす名前を持つ短いメソッドは、コメントの必要性を排除し、バグを明白にし(各メソッドは一目で検証するほど小さい)、再利用を可能にします。名前がすべてを伝えるとき、メソッド呼び出しの認知コストはほぼゼロです。

重要な洞察:

• Extract Methodが最も重要なリファクタリングです。最初にマスターしてください
• コメントを書きたい衝動を感じたら、コードブロックを抽出し、コメントをメソッド名として使用します
• メソッドボディが名前と同じくらい明確なときはInline Methodを使用します。価値のない間接参照はノイズです
• Replace Temp with Queryを使用します。計算値を保持し複数の場所で使用される一時変数の場合
• Split Temporary Variableを使用します。1つの変数が2つの異なる目的で再利用される場合
• Replace Method with Method Objectを使用します。メソッドが抽出するにはあまりに絡み合っている場合(多くのローカル変数が相互参照)

コード適用:

文脈	パターン	例
コメント付きブロック	Extract Method	// check eligibilityがisEligible()になる
一度だけ使用される一時変数	Inline Variable	一度だけ使用される場合const price = order.getPrice()を削除
複数の場所で使用される一時変数	Replace Temp with Query	let discount = getDiscount()をメソッド呼び出しで置き換える
2つの異なる理由で2回割り当てられた一時変数	Split Temporary Variable	perimeterWidthとperimeterHeightを導入
自明な委任メソッド	Inline Method	moreThanFiveDeliveries()がreturn deliveries > 5であり一度だけ使用される場合、inline
多くのローカル変数を持つ複雑なメソッド	Replace Method with Method Object	メソッドを独自のクラスに移動し、ローカルはフィールドになる

参照: references/composing-methods.md

3. オブジェクト間での機能の移動

コアコンセプト: オブジェクト指向設計での重要な決定は、責務をどこに置くかです。メソッドまたはフィールドが間違ったクラスにある場合(Feature Envy、過度な結合、またはクラスサイズの不均衡で証明される)、それが属する場所に移動します。

なぜ機能するか: よく配置された責務は結合を削減し、凝集度を高めます。メソッドがそれが使用するデータのクラスに存在する場合、そのデータへの変更は1つのクラスだけに影響します。誤配置されたメソッドは見えない依存関係を作成し、Shotgun Surgeryを引き起こします。

重要な洞察:

• Move Methodを使用します。メソッドが自分のクラスより別のクラスの機能をより多く使用する場合
• Move Fieldを使用します。フィールドが存在するクラスより別のクラスで多く使用される場合
• Extract Classを使用します。1つのクラスが2つのことを行う場合。変更の軸に沿って分割
• Inline Classを使用します。クラスの存在を正当化するほど十分小さい場合
• Hide Delegateを使用します。Law of Demetersを強制するために。クライアントはオブジェクトのチェーンをナビゲートすべきではありません
• Remove Middle Manを使用します。クラスが呼び出しをリダイレクトするだけの場合
• Hide DelegateとRemove Middle Manの間のテンションはケースバイケースで解決されます。チェーンが不安定な場合は委任者を隠す。リダイレクトがクラス全体になる場合はミドルマンを削除

コード適用:

文脈	パターン	例
メソッドが別のクラスに嫉妬している	Move Method	calculateShipping()をOrderからShippingPolicyに移動
別のクラスで常に使用されるフィールド	Move Field	discountRateをOrderからCustomerに移動
500行以上の神クラス	Extract Class	Addressフィールドとメソッドを独自クラスに引き出す
1つのフィールドを持つ小さなクラス	Inline Class	動作がない場合PhoneNumberをContactに統合
クライアントが a.getB().getC()を呼び出す	Hide Delegate	a.getCThroughB()を追加し、クライアントがCを知らないようにする
クラスがリダイレクト呼び出しのみ	Remove Middle Man	クライアントが委任者を直接呼び出すようにする

参照: references/moving-features.md

4. データの整理

コアコンセプト: 生データ(マジックナンバー、公開フィールド、整数として表現された型コード、並列配列)は微妙なバグを作成し、ドメイン知識を分散させます。プリミティブ表現を、動作をカプセル化し不変条件を強制するオブジェクトに置き換えます。

なぜ機能するか: 通貨金額を表すintには、丸めルール、通貨コード、またはフォーマットの概念がありません。Moneyオブジェクトはそれをすべてカプセル化します。ドメイン概念がファーストクラスオブジェクトとして表現される場合、ビジネスルールは1か所に存在し、検証は自動的に発生し、型システムはコンパイル時にエラーをキャッチします。

重要な洞察:

• Replace Magic Numberを使用します。Symbolic Constantを最も単純なデータリファクタリングとして。意図に名前を付けます
• Replace Data Value with Objectを使用します(Primitive Obsession治療法)。文字列と数値をドメインオブジェクト(EmailAddress、Money、Temperature)でラップ
• Encapsulate Fieldを使用します。生フィールドを決して公開しません。getter/setterは後で検証、ロギング、または計算を追加することができます
• Encapsulate Collectionを使用します。変更不可能なビューを返します。呼び出し者が内部リストを変更させません
• Replace Type Code with Subclassesを使用します。型コードが動作に影響する場合。サブクラス化が非実用的な場合はStrategyを使用
• Change Value to Referenceを使用します。同一性セマンティクスが必要な場合(1つの共有Customerオブジェクト、コピーではなく)

コード適用:

文脈	パターン	例
if (status == 2)	Replace Magic Number with Symbolic Constant	if (status == ORDER_SHIPPED)
String emailがどこでも渡される	Replace Data Value with Object	EmailAddressクラスを検証付きで作成
パブリックフィールド	Encapsulate Field	order.totalをorder.getTotal()に置き換える
Getterが変更可能なリストを返す	Encapsulate Collection	Collections.unmodifiableList(items)を返す
Switch付きint typeCode	Replace Type Code with Subclasses	Employee -> Engineer、Manager、Salesperson
重複した顧客レコード	Change Value to Reference	レジストリ経由で1つのCustomerインスタンスを共有

参照: references/organizing-data.md

5. 条件付きロジックの単純化

コアコンセプト: 複雑な条件付き(深くネストされたif/elseツリー、長いswitchステートメント、散在したnullチェック)は最も読みにくく、バグを含む可能性が最も高いコードです。名前付きリファクタリングは、条件付きを分解、統合、および置き換えてより明確な構造にします。

なぜ機能するか: 6つのブランチと入れ子になった副条件を持つ条件付きは、すべてのパスを頭の中でシミュレートするよう読者に要求します。条件をよく名前が付けられたメソッドに分解すると、各ブランチが自己文書化されます。条件をポリモーフィズムで置き換えると、「このケースの処理を忘れた」バグの全カテゴリが削除されます。

重要な洞察:

• Decompose Conditionalを使用します。条件、then-ブランチ、else-ブランチを名前付きメソッドに抽出
• Consolidate Conditional Expressionを使用します。同じ結果につながる複数の条件を1つの名前付きチェックにマージ
• Replace Nested Conditional with Guard Clausesを使用します。エッジケースを早く処理して戻り、メインパスをインデント解除
• Replace Conditional with Polymorphismを使用します。型ベースの条件の金準。各型は独自の動作を知っています
• Introduce Special Case (Null Object)を使用します。if (x == null)チェックを排除。「何もない」を表すオブジェクトを提供し、安全なデフォルト動作を持たせます
• Introduce Assertionを使用します。仮定を明示的にし、開発時に早く失敗します

コード適用:

文脈	パターン	例
複雑な条件を持つ長いif	Decompose Conditional	isSummer(date)とsummerCharge()を抽出
複数のifが同じ値を返す	Consolidate Conditional	1つのisDisabled()に結合し、早期に戻す
深くネストされたif/else	Replace with Guard Clauses	エッジケースを最初にチェック、早期に戻す、メインパスを平坦化
オブジェクト型のswitch	Replace Conditional with Polymorphism	各型は独自のcalculatePay()を実装
どこでもif (customer == null)	Introduce Special Case	デフォルト動作を持つNullCustomerを作成
コードの隠れた仮定	Introduce Assertion	メソッド入口でassert quantity > 0

参照: references/simplifying-conditionals.md

6. 安全なリファクタリングワークフロー

コアコンセプト: リファクタリングはテストでラップされた場合のみ安全です。ワークフローは機械的です。テストを実行(グリーン)、1つの小さな変換を適用、テストを実行(グリーン)、コミット。テストが赤くなったら、最後の変更を戻す。壊れたリファクタリングをデバッグしないでください。

なぜ機能するか: 小さなステップにより、何が問題かを見つけるのは簡単です(それは最後にしたことです)。失敗したステップを戻すコストは数秒です。失敗したビッグバン的な書き直しをデバッグするコストは数日かかります。頻繁なコミットは戻ることができるセーブポイントを作成します。

重要な洞察:

• リファクタリングサイクル: test -> refactor -> test -> commit (繰り返し)
• Rule of Three: 1回目の重複を許容し、2回目にそれを指摘し、3回目に出現時にリファクタリング
• Preparatory refactoring: 機能を追加する前にコードを再構築して機能を簡単にする
• Comprehension refactoring: コードを読むときにリファクタリングして理解する。発見したより明確に去る
• Litter-pickup refactoring: ファイルに触れるときはいつでも小さな改善(Boy Scout Rule)
• リファクタリング禁止時: 最初から書き直すほうが簡単な場合、テストなしのコードで最初にそれらを追加することが可能でない場合、またはコードが間もなく削除される場合
• リファクタリングとパフォーマンス: 最初に明確さのためリファクタリング。その後プロファイリングして測定ボトルネックを最適化。リファクタリングされたコードはホットパスが分離されているため調整が簡単です
• Branch by AbstractionとParallel Changeは、フィーチャーブランチなしで本番システムの大規模リファクタリングを可能にします

コード適用:

文脈	パターン	例
機能を追加する予定	Preparatory Refactoring	メソッドを抽出し、新機能の挿入ポイントをきれいにする
不慣れなコードを読む	Comprehension Refactoring	変数の名前を変更してメソッドを抽出し、意図を理解
作業中に小さな問題を発見	Litter-Pickup Refactoring	先に進む前にスメルを修正(Boy Scout Rule)
同じロジックの3番目のコピー	Rule of Three	共有ロジックを共通メソッドに抽出
本番での大規模なAPI変更	Branch by Abstraction	抽象化レイヤーを導入、呼び出し者を移行、古いパスを削除
広く使用されるメソッドの名前変更	Parallel Change	新しい名前を追加、古いものを非推奨化、呼び出し者を移行、古いものを削除

参照: references/refactoring-workflow.md

一般的な間違い

間違い	失敗する理由	修正
テストなしのリファクタリング	安全ネットがない。動作が変わったか判断できない	最初に特性化テストを書いてからリファクタリング
増分的ステップの代わりにビッグバン書き直し	構造的変更と動作的変更を組み合わせる。デバッグ不可能	できる限り最小のステップを踏み、それぞれの後にテストを実行
リファクタリングと機能追加を同時に行う	一度に2つの帽子。各変更を分離して検証できない	帽子を分離: 最初にリファクタリング(コミット)、その後機能追加(コミット)
すべての呼び出し元を更新せずに名前変更	ビルドを壊すか、デッドコードを導入	IDE rename refactoring使用。すべてのリファレンスを検索
多くの小さなメソッドを抽出しすぎ	名前が悪い場合、明確性なしに間接参照を作成	抽出された各メソッドは、ボディを読む必要を削除する名前を持つ必要
スメルカタログを無視	証明されたレシピの代わりに修正を再発明	名前付きスメルを学習。各1つは特定のリファクタリングにマップ
削除されるコードのリファクタリング	無駄な努力。非難されたコードの磨き	最初に確認:このコードの寿命は投資を正当化するほど十分長いですか?
リファクタリング中の早期最適化	明確さとパフォーマンスを混同。最適化コードはしばしば読みにくい	最初に明確さのためリファクタリング、その後プロファイリング、測定ホットパスのみを最適化

クイック診断

質問	いいえの場合	アクション
開始前にテストが通りますか?	安全ネットがない	最初にテストを書くか修正。グリーンテストなしでリファクタリングしない
修正しているスメルに名前を付けられますか?	本能でリファクタリング、カタログではない	カタログからスメルを特定し、その規定のリファクタリングを適用
各メソッドは~10行未満ですか?	Long Methodが存在している可能性	Extract Methodを適用して長いメソッドを名前付きステップに分割
各クラスは変更の単一の理由を持っていますか?	Divergent ChangeまたはLarge Class smell	Extract Classを適用して責務を分離
重複したコードブロックはありますか?	Duplicate Codeは最も高い負債スメル	共有ロジックを共通メソッドまたはベースクラスに抽出
条件付きは適切な場所でポリモーフィズムを使用していますか?	Switch StatementsまたはSwitch Conditionalまたは複雑なif/elseツリーが残っている	Replace Conditional with Polymorphismを適用
各リファクタリングステップ後にコミットしていますか?	作業を失う場合があり、変更が混じる	すべてのグリーンからグリーンへの変換の後にコミット
変更後のコードはより読みやすいですか?	リファクタリングが複雑性を追加した可能性	戻して別のアプローチを試す

リファレンスファイル

• smell-catalog.md: コードスメルの包括的なカタログ。ファミリー別に整理(Bloaters、Object-Orientation Abusers、Change Preventers、Dispensables、Couplers)。検出ヒューリスティクスと修正マッピング
• composing-methods.md: Extract Method、Inline Method、Extract Variable、Inline Variable、Replace Temp with Query、Split Temporary Variable、Remove Assignments to Parameters、Replace Method with Method Object。動機、メカニクス、例
• moving-features.md: Move Method、Move Field、Extract Class、Inline Class、Hide Delegate、Remove Middle Man。いつ、どのようにしてオブジェクト間で責務を再配分
• organizing-data.md: Replace Data Value with Object、Change Value to Reference、Replace Array with Object、Replace Magic Number、Encapsulate Field、Encapsulate Collection、Replace Type Code with Class/Subclasses/Strategy
• simplifying-conditionals.md: Decompose Conditional、Consolidate Conditional、Replace Nested Conditional with Guard Clauses、Replace Conditional with Polymorphism、Introduce Special Case、Introduce Assertion。ビフォー/アフター例付き
• refactoring-workflow.md: リファクタリングサイクル、リファクタリング時期、リファクタリング禁止時、リファクタリングとパフォーマンス、Branch by Abstraction、Parallel Change

さらに読む

このスキルは既存コード設計改善の決定的なガイドに基づいています:

• "Refactoring: Improving the Design of Existing Code (2nd Edition)" by Martin Fowler
• "Working Effectively with Legacy Code" by Michael Feathers (テストなしコードのコンパニオン)
• "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin (補足的な命名とスタイル原則)

著者について

Martin FowlerはThoughtworksのChief Scientistであり、ソフトウェアエンジニアリングで最も影響力のある声の1つです。彼はRefactoring: Improving the Design of Existing Code(1999、第2版2018)の著者であり、名前付きカタログベースのリファクタリング変換の概念をメインストリームソフトウェア開発に導入しました。FowlerはまたPatterns of Enterprise Application Architecture、UML Distilledの著者であり、ソフトウェア設計、アジャイル方法論、継続的デリバリーに関する多くの影響力のある記事を著述しています。彼はAgile Manifestoの署名者であり、進化的設計の実践(規律ある増分的なリファクタリングを通じてコード構造を継続的に改善する)を数十年間推奨しています。彼のリファクタリングカタログはもともとJavaで書かれていますが、実質的にすべてのプログラミング言語に適応されており、すべての主要IDEの自動リファクタリングツールに組み込まれています。