これはArmaiz Adenwalaからのゲスト投稿です。ArmaizはHipcampのモバイルアプリ体験を担当しています。
React Nativeのアップグレードは、常にエンジニアにとって恐ろしいタスクでした。不慣れなネイティブコード、重要なライブラリに触れ、破壊的な変更を解決する必要があります。十分にテストされていないと、何でもエラーを引き起こす可能性があります。時間とともに、React Native Upgrade helperのようなツールがプロセスを簡素化し、Expoのようなフレームワークがこのプロセスをより滑らかにするために構築されました。
アップグレードの複雑さ
残念ながら、すべてのReact Nativeアプリが完璧な状態にあるわけではありません。ペースの速い企業が依存関係の保守と機能の配信のバランスを取ることは非常に困難です。その結果、アップグレードはより大きな取り組みになります。
Hipcampでは、最近New Architecture + Expo 54へのアップグレードという課題に直面しました。New Architectureでは、数十のライブラリが古くなっており、アップグレードまたは置き換える必要がありました。React Nativeを十分に使用していれば、単に最新バージョンにバンプするだけでは不十分であることをご存知でしょう。デバッグと問題解決に多くの時間が費やされます。さらに、複数のライブラリが互いに競合する可能性があり、2つの間で互換性のあるバージョンを見つける必要があります。
幸いなことに、今回は既にScoutを構築していました。これは、投げかけるあらゆるタスクに対処するために設計されたAIエージェントです。エンジニアが数週間の退屈な依存関係の調査とバージョン解決に費やしたであろう時間を、Scoutは数日間にわたるいくつかの焦点を絞ったセッションで処理しました。Scoutのような内部エージェントを持つことは役に立ちますが、純粋なClaude Codeを使用してReact Nativeアップグレードに対処する方法を共有します。
Scoutがアップグレードを加速させた
アップグレード前のHipcampアプリの状態
セキュリティアップデート以外でアプリのバージョン管理を十分に保つことができていませんでした。放棄されたパッケージ、4～6年前の古いパッケージなど。100以上の依存関係があり、そのうち約40がNew Archをサポートするためにアップグレードする必要がありました。当社がリーンな企業であるため、通常の製品作業の上にアップグレードを行うサイクルがありませんでした。コストの問題ではなく、時間の問題でした。この大規模なアップグレードに数ヶ月間エンジニアを影響力のあるプロジェクトから外すことを正当化することはできませんでした。
アップグレードのスコープ方法
このアップグレードをどのように達成したかについて説明する前に、プロンプトを設計するためにこのプロセスの主要な目標について議論する必要があります。以下に決定しました：
- 必要な依存関係のみに焦点を当てる - 現在new archをサポートしていない、または16kb androidをサポートしていないライブラリのみをアップグレードします
- 依存関係をExpo相当に置き換える - Expoのモジュールはよく保守され、信頼性があり、人気があります
- 最後の手段としてpatch-packageを活用する
アップグレードワークフロー
その後、このアップグレードプロセスをどのように進めたいかを決定しました。マルチフェーズアプローチを構築する必要があることを決定しました。作業の各フェーズにどれだけの時間/お金を費やしたいかを決定する必要がありました。最終的に、トークンはエンジニアがドキュメント、コード、Githubの問題を疲れ果てて移動するよりもはるかに安いことに気づきました。さらに言えば、エンジニアは節約した時間を、収益をもたらす製品機能の開発に費やしました。したがって、予算がこのプロジェクトを制限しないようにするのは当然のことでした。
フェーズ1：エージェントを構築する
Scoutのようなエージェントを内部で構築するか、Expoのアップグレードスキルを活用することを強くお勧めします。エージェントにコードベースを教え、コードベースのアーキテクチャをインデックスする方法を設計します。/scout-document-architectureドキュメンター コマンドを実行して、アプリのあらゆる側面と詳細に関するメモを取るのに1日を費やしました。これにより、Scoutが幻覚を見たり、何かを見落としたりするのを防ぎました。
フェーズ2：すべての依存関係を監査する
すべての依存関係を監査するタスクにエージェントを送信しました。sqlite dbを使用してすべてを追跡することをお勧めします。このdbをプロジェクト管理ツールに同期するか、マークダウンファイルを使用することができます。その後、プロンプトを提供しました。以下は、当社が提供したものの例です：
Expo SDK 50 → 54 依存関係監査
Expo 50 → 54アップグレード互換性のためにアプリのすべての依存関係を監査します。
コンテキスト
- 現在： Expo 50（RN 0.73、React 18.2）
- ターゲット： Expo 54（RN 0.81、React 19.1）
- Expo 52+はデフォルトでNew Architectureを有効にします
- Expo 52+は16kb Androidページサイズサポートが必要です
リサーチ
各依存関係について、以下を実行する必要があります：
- GitHubの変更ログ/リリースを読む Expo 50とExpo 54互換バージョン間
- GitHubの問題を検索する バグ、エラー、リスク、苦情について
- セットアップドキュメント とマイグレーションガイドを読む
- 他の依存関係との競合を確認する スタック内
- セットアップスイッチがリスキーまたは複雑かどうかを確認する
その後、以下に答えます：
- これはExpoモジュールで置き換えることができますか？
- これは完全に削除することができますか？
- GitHubの問題に既知のNew Archブロッカーがありますか？
- 16kbページサイズの問題が報告されていますか？
- これはピア依存関係の競合を持っていますか？
- アップグレードパスは滑らかですか、それともコード変更が必要ですか？
- コミュニティの苦情が最近のバージョンについてありますか？
サブエージェント戦略
- 1つのサブエージェント 小さい/シンプルなJSのみの依存関係用
- 5つのサブエージェント 中程度/より難しいネイティブ依存関係用
- 10のサブエージェント 極度に複雑な依存関係用（react-nativeコア、reanimated、maps、firebase、sentry）
- 各サブエージェントは正確に1つの依存関係で動作します — バッチ処理しないでください
出力
./dependencies/{name}.md内の依存関係ごとに1つのメモファイル./dependencies.dbのSQLite DB（列：name、expo_50_version、max_version_expo_50、expo_54_version、new_arch_support、sixteenkb_support、status、type（javascript/native）、change_recommendation（upgrade/remove/swap）、swap_target、complexity（0-10）、notes）- 可能であれば、Expo相当ライブラリで置き換えることを常に優先する
- 依存関係を1つずつ処理します — 先に進まないでください
リファレンス
フェーズ3：レビューしてアップグレードを開始する
その後、各アップグレード項目を手動で確認し、すべてが正しく見えることを確認しました。削除すべきではないライブラリを削除していないことを確認し、推奨されている場合は正しい代替ライブラリを選択します。利用可能な場合はExpoのライブラリを使用することを強くお勧めします。これらは積極的に保守され、よく文書化されています。
プロセスの文書化
完了後、すべてのアップグレードのためにprを作成するために働くエージェントを送信しました。当社の場合、初期実行は3日間の継続的なアップグレードでした。長時間実行されるタスクを扱う場合、すべてのステップでサブエージェントを使用することを強くお勧めします。各依存関係を独自のコンテキストに保つことは、信頼性の高いアップグレードに重要です。以下のプロセスを提供しました：
- 依存関係を選択する
- サブエージェントを送信して前のステップからのメモを確認する
- 1～3のサブエージェントが指定されたバージョンへのアップグレードを試みる
- 完了したら、レビュアーサブエージェントを送信して変更をレビューする
- yarn lint、tsc、およびreact native bundleを実行し、発生したエラーに対処する
- iOSとAndroidのEASビルドを作成し、ビルドが成功したことを検証します。発生する可能性のあるエラーに対処する
- iOSとAndroidの最終EASビルドを作成する
- prを作成し、ビルド、手動QAステップ、影響を受けるスクリーン、その他すべてを追加する
戻ってきたとき、レビューするための多くのprがありました。すべてのprを確認するのは非常に迅速でした。もちろん、エンジニアの密接な関与が必要なprがいくつかありましたが、エージェントがすでにすべてのコンテキスト、ドキュメント、関連するGithubの問題などをprで共有していたため、簡単に作業できました。
当社の経験から、New Architectureビルドの問題をデバッグするのに1週間しか費やしませんでした。アップグレードプロセス全体は、2～3ヶ月と推定されていたものから数週間に短縮されました。1四半期からスプリントへ。
当社の依存関係の状況は非常に懸念されていました。より小さなアプリの場合、さらに少ない時間を費やすことに気付くかもしれません。もちろん、ポーランド化はまだありましたが、大部分の作業は完了していました。
フェーズ4：QA、ロールアウト、監視
非常に安全なロールアウトが必要でした。Hipcampの同僚がアプリを使用してバグを指摘することを要求しました。QAパーティーを開催し、会社の人々が一緒にアプリをQAしました。これらは非常に生産的です。その後、iOSとAndroidのスローロールアウト機能を使用しました。iOSを最初にリリースしてから、iOSで自信を感じた後、Androidをリリースしました。
監視
エラー追跡の何らかの形式を配置することが重要です。さらに、パフォーマンスプロファイリングをアプリに統合することをお勧めします。多くのものがあり、その1つはExpo Observeです。幸いなことに、彼らのプライベートプレビューの参加者です！また、エージェントが発生したエラーを監視して修正しました。QAパーティーからのものであろうと本番環境からのものであろうと、エージェントはエンジニアの最小限の関与でほとんどのバグを解決することができました。
驚いたことに、New Architecture以外に大きな新しいエラーは見られませんでした。実際、エラーの総数は減少しました。これは、エンジニアが複雑な作業を解決し、徹底的にQAを行うのに時間を費やすことができ、エージェントが残りを処理するという事実に起因しています。
結論
AIはエンジニアの働き方を変えています。ドキュメントをスキミングし、締め切りに対抗し、不明瞭な問題をデバッグするのに費やされた時間は、すぐに過去のものになるかもしれません。このアップグレードは、AIエージェントが重要で困難なプロジェクトの信頼できるパートナーになることができ、AI支援エンジニアリングの真の利点はエンジニアを置き換えることではなく、退屈なものを通じて苦労する代わりに複雑な問題に焦点を当てるために彼らを解放することであることの証拠でした。