挙動を保ったまま行う単一画面のリファクタリング

SwiftUI で画面全体の実装が 1 つのファイルに膨らみ、少し手を加えるだけでも影響が心配になるときに使える方法です。機能の再設計や新しいアーキテクチャの導入は目的ではありません。画面の挙動とレイアウトを維持しながら、データの流れが明確な小さなサブビューに分割するよう Codex に依頼します。こうしておくと、次の変更をレビューしやすくなります。

このような整理には、Build iOS Apps プラグインを使います。このプラグインの SwiftUI ビュー向けリファクタリングスキルには、明確な設計方針があります。原則として MVVM よりも MV を優先し、ビジネスロジックはサービスやモデルに置きます。まずはビューのローカルな状態と環境から取得できる依存関係を使い、その機能に明らかに必要な場合に限ってビューモデルを残します。

Codex への依頼内容

まず対象の画面ファイルを 1 つ指定し、挙動を維持しながら構造を改善するよう Codex に依頼します。プロンプトには、次のリファクタリング方針を明記するとよいでしょう。

• 環境から取得する依存関係、格納プロパティ、ビュー以外の状態を表す計算プロパティ、init、body、ビューを組み立てるヘルパー、ヘルパーメソッドの順に並べ、ファイルを上から読み進めやすくします。
• 意味のあるまとまりごとに専用の View 型として切り出し、必要最小限の入力値、@Binding、コールバックを明示します。
• some View を返す計算プロパティは必要な箇所に限り、短く保ちます。大きな画面を細切れにして、非公開の計算プロパティをいくつも並べる構成は避けます。
• ボタンを押したときの複雑な処理や副作用は body の外に出し、ビジネスロジックはサービスやモデルに移します。
• ルートのビュー階層は安定させます。最上位の if/else 分岐で画面全体を切り替えるよりも、セクションやモディファイアの中で必要な部分だけを条件分岐させます。
• リファクタリングに合わせて、Observation を使うモデルの所有関係に問題があれば修正します。iOS 17 以降では、ルートの @Observable モデルを所有するビューが、そのモデルを @State に保持します。従来の監視用プロパティラッパーは、デプロイ対象の OS バージョンで必要な場合に限って使います。

切り出しごとの小さな検証

挙動を維持するリファクタリングでは、実際に挙動が保たれていることを確かめます。ひとまとまりのビューを切り出すたびに、ビルド、プレビュー、テスト、シミュレータでの動作確認のうち、その画面を検証できる最小限のものを実行するよう Codex に依頼します。そのうえで、構造上の変更点と、意図して維持した点をまとめてもらいます。

実践のヒント

アーキテクチャの検討に先立つ画面分割

画面の実装が大きすぎる場合は、新しい抽象化レイヤーを導入する前に、セクションごとにビューを切り出すよう Codex に依頼します。ビュー階層がコンパクトになり、構造が明確になるだけで、ビューモデルを追加する必要がなくなることもよくあります。

各サブビューに渡すインターフェースの最小化

すべての子ビューに親のモデル全体を渡すのは避け、let で受け取る値、@Binding、用途を 1 つに絞ったコールバックを優先します。切り出したセクションを個別にプレビューしやすくなり、意図せず画面全体に再び依存することも防ぎやすくなります。

意図して維持した点の明示

リファクタリングを安全に進めるには、ビジネスルール、画面遷移の挙動、データの永続化、分析用データが表す意味、ユーザーに見えるレイアウトなど、変更しなかった点を Codex に明示してもらうと効果的です。レビューにかかる時間を大幅に短縮できます。