動作を変えない単一画面のリファクタリング

SwiftUI ファイルが 1 つの巨大な画面へと肥大化し、どんな小さな編集にもリスクを感じるようになったときに役立つユースケースです。目的は、機能を再設計したり、新しいアーキテクチャを考案したりすることではありません。動作とレイアウトを維持したまま、明示的なデータフローを持つ小さなサブビューへ画面を分割するよう Codex に依頼すれば、その後の変更をレビューしやすくなります。

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

Codex への依頼内容

まず、対象となる具体的な画面ファイルを 1 つ指定し、動作を維持しながら構造を改善するよう Codex に依頼します。プロンプトに直接含めると効果的なリファクタリングルールは次のとおりです：

• ファイル内の順序を、環境依存関係、格納プロパティ、ビューを返さない計算プロパティ、init、body、ビューヘルパー、ヘルパーメソッドの順に並べ替え、上から下へ追いやすくしてください。
• 意味のあるセクションを専用の View 型として抽出し、必要最小限の明示的な入力、@Binding、コールバックを持たせてください。
• 計算プロパティとして定義する some View ヘルパーは、必要最小限の小さなものにしてください。1 つの巨大な画面を、private な計算プロパティのビューフラグメントを長々と並べるだけの構成に作り直さないでください。
• 複雑なボタンアクションや副作用は body の外に移し、実際のビジネスロジックはサービスまたはモデルに移してください。
• ルートのビューツリーを安定させてください。画面全体を入れ替えるトップレベルの if/else 分岐ではなく、セクションやモディファイアーで局所的に条件を適用する方法を優先してください。
• 作業を進めながら Observation の所有関係を修正してください。iOS 17+ でルートの @Observable モデルを所有するビューは、そのモデルを @State で保持してください。従来の Observable ラッパーは、デプロイメントターゲットの都合で必要な場合にのみ使用してください。

小さな検証ループの実行を依頼

動作を維持するリファクタリングには、裏付けが必要です。意味のある抽出を行うたびに、画面の動作を確認できる最小限のビルド、プレビュー、テスト、またはシミュレーターチェックを実行し、続けて構造上の変更点と意図的に維持した点をまとめるよう Codex に依頼してください。

実践的なヒント

まず分割、アーキテクチャの検討はその後

画面が大きすぎる場合は、新しい抽象化レイヤーを導入する前にセクションビューを抽出するよう Codex に依頼してください。ビューツリーを短く明示的にするだけで、ビューモデルを追加する必要性そのものが解消されることもよくあります。

各サブビューに渡すインターフェースを必要最小限に

各子ビューに親モデル全体を渡すのではなく、let 値、@Binding、単一用途のコールバックを優先してください。これにより、抽出した各セクションをプレビューしやすくなり、画面全体へ誤って再び密結合させることも避けやすくなります。

意図的に変えなかった点の明記を Codex に依頼

安全なリファクタリングでは、変更しなかったもの、つまりビジネスルール、ナビゲーションの動作、永続化、アナリティクスのセマンティクス、ユーザーに見えるレイアウトを Codex が明示的に列挙すると役立ちます。これにより、レビューを大幅に迅速化できます。