project-auditor-fixes

Project Auditor の使用方法 Project Auditor は Unity プロジェクトの静的解析スキャンを実行し、修正できる可能性のある問題を CSV 形式の一覧で報告します。トリガーし、状態をポーリングして、結果を読み取ります。

前提条件

Project Auditor を使用するには、Unity CLI がインストールされている必要があります。詳しくは unity-cli スキルを参照してください。 インストール後、audit コマンドと audit_status コマンドで Project Auditor のチェックを実行できます。

unity command audit                              # optional: --categories Code,ProjectSetting --output my.csv
unity command audit_status                       # repeat until a terminal status is returned

audit_status の最終ステータスは completed（csvPath と issueCount を含む）、failed、unavailable、interrupted（ドメインのリロードによってスキャンが終了した状態です。その場合は audit を再実行してください）です。アセンブリのコンパイル中やメインスレッドがビジー状態のときも、ポーリングは応答します。一度に実行できるスキャンは 1 つだけです。2 つ目の audit を実行すると busy が返されます。キャンセル機能はありません。スキャンを中断する場合は、ポーリングを停止してください。

出力 CSV の列は Category, Severity, Areas, Description, RelativePath, Line, DescriptorId, Recommendation です（これらは診断項目のみなので、すべての行が修正対象です。修正方法は Recommendation に記載されています）。

Project Auditor とそのルールが必要です。 unavailable は、Editor に Project Auditor がないか、解析ルールがないことを意味します。組み込みモジュールの Editor では、ルールは別個の com.unity.project-auditor-rules パッケージに含まれています（unity command package_add --identifier com.unity.project-auditor-rules --confirm true）。message フィールドを確認してください。このコマンドが、プロジェクトに問題がないように見える空の completed スキャンを報告することはありません。

注意点

• まず set_autotick を設定します。 設定しないと、エディターのフォーカスが外れている間に再コンパイルやテストが停止することがあります。パッケージのウォッチドッグは、tick ループが動作し続けることを前提としています。
• ホットリロードにはゲームの実行が必要です。 reload_file_override / reload_file は実行中のゲームに適用されます。先に Editor の Play Mode（unity command editor_play）に入るか、開発用 Player を実行してください。
• Player 専用のコマンドには開発用 Player が必要です。 log、set_timescale、runtime_status などは Runtime サーバーにアクセスします。このサーバーは Editor では実行されません。
• 非同期コマンドはポーリングします。 recompile の後は recompile_status、run_tests --async_tests の後は test_status を実行します。トリガー呼び出しの応答だけで完了したと判断しないでください。
• 複数のインスタンスが実行中の場合は、 --instance host:port または --project-path <path> を指定して、特定のインスタンスを対象にします。

ベストプラクティス

問題の一覧を修正する際は、正常に動作し続けていることを確認するために、テストケースを用意することをおすすめします。特定のシーンを開いて Play Mode を開始する場合や、特定のプラットフォーム向けにビルドして実行する場合などが考えられます。テストケースがなく、手順の指示もない場合は、テストケースをユーザーに提案し、確認を求めてください。プロジェクトが引き続き正常に動作することを確認するため、変更の前後にテストケースを実行してください。

作業中は、ユーザーのバージョン管理の設定に合わせて、変更をコミットしてください。可能な限り、変更をユーザーが理解しやすい単位に分割し、段階的にコミットしてください。

手順

1. プロジェクトがエラーなく開くことを確認します（エディターでコンパイルエラーなどが発生しない状態にします）。問題がある場合はユーザーに確認してください。ユーザーが把握していて、無視したい場合があります。テストケースを実行し、現在の状態を把握して、必要に応じて修正します。
2. バージョン管理をクリーンな状態にしてアップグレードプロセスを開始できるよう、変更をすべてコミットします。
3. Unity エディターでプロジェクトを開きます。その後、Unity CLI を使って監査コマンドを実行します。
4. 問題をファイル別、種類別に分類します。
5. 問題の種類を選び、グループまたはファイルごとに対応します。 5.a. アセットまたはプロジェクトの設定に関する問題は、種類ごとに修正することを基本とします。 5.b. コードに関する問題は、ファイルおよびサブフォルダーごとに修正することを基本とします。 5.c. ただし、問題は人が対応・レビューしやすい単位に分けて修正することが重要です。 5.c.i. 多数のファイルに同じ小さな変更を加える場合（たとえば、多数のテクスチャのブール設定を切り替える場合）は、1回のコミット、またはサブフォルダーごとのコミットにまとめるのが適切でしょう。 5.c.i.. コードを変更する場合は、コミットごとにコンパイルが通る状態にします。 5.d. Project Auditor の推奨事項に基づいて変更を加え、エディターにエラーがなくなったら各変更をコミットします。