harmonyos-review

HarmonyOS コードレビュー

チェックリストありきの憶測ではなく、実際の欠陥を見つけます。リポジトリのコードと設定がアプリケーションの動作を規定し、Huawei の公式ドキュメントがバージョンに依存するプラットフォームの契約を規定します。

1. レビュー範囲を確定する

• レビュー前にリポジトリの指示を読み、作業ツリーの状態を確認します。
• 要求された境界を特定します: diff/PR、ファイル、モジュール、サブシステム、リポジトリ全体のいずれかです。
• 変更レビューの場合は、正確なベースを特定し、diff と影響を受ける呼び出し箇所の両方を確認します。
• build-profile.json5、oh-package.json5、module.json5、および関連する設定を読み、SDK レベル、アプリケーションモデル、デバイス、パーミッション、依存関係、ビルドバリアントを把握します。
• ユーザーが求めない限り、コードの変更、レポートの作成、評価の付与、工数の見積もりは行いません。

2. 関連する実行パスを把握する

まず広く確認し、その後エビデンスを追跡します:

• エントリポイント、ライフサイクルコールバック、状態のオーナー、非同期境界、永続化操作、ファイル操作、パーミッション、イベント購読、外部入力を特定します。
• 呼び出し元と呼び出し先を通じて値とリソースを追跡します。クリーンアップ、キャンセル、リトライ、失敗、部分成功のパスを確認します。
• 意図された動作についてテストとドキュメントを確認しますが、それらを本番コードが安全である証拠として扱ってはいけません。
• 絞り込んだ検索を使って候補を見つけます。テキストの一致は手がかりであり、決して指摘事項ではありません。

偵察コマンドの例:

rg -n --glob '*.ets' --glob '*.ts' 'eventHub\.(on|off)|emitter\.(on|off)|setInterval|setTimeout'
rg -n --glob '*.ets' 'ResultSet|relationalStore|executeSql|beginTransaction|commit|rollBack'
rg -n --glob '*.ets' 'requestPermissionsFromUser|checkAccessToken|canIUse'
rg -n --glob '*.ets' --glob '*.json5' '(password|secret|token|api[_-]?key)'
rg -n --glob '*.json5' 'compileSdkVersion|compatibleSdkVersion|targetSdkVersion|requestPermissions'

パターンはリポジトリに合わせて調整してください。ノイズの原因になる場合は、生成物、依存関係、ビルド出力、フィクスチャ、テストデータのディレクトリを除外します。

3. 該当するカテゴリのみを分析する

references/checklist.md を読み込み、範囲によって裏付けられるカテゴリを選択します:

• 正確性とエラー伝播
• セキュリティ、プライバシー、機密データ
• ライフサイクル、リソースの所有権、キャンセル
• V1/V2 の状態管理と並行更新
• RDB、Preferences、ファイル、マイグレーション、原子性
• パーミッション、SysCaps、デバイス、API 互換性
• ネットワークと外部入力の処理
• 具体的で高コストなパスがあるパフォーマンス問題
• 変更された、または高リスクな動作をカバーするテスト

プラットフォームに依存する主張については、references/official-docs.md を参照し、現在の Huawei の公式ドキュメントと照合して検証します。「現在の」API バージョンをハードコードしたり、別のフレームワークから要件を推測したりしないでください。

4. 各指摘事項を証明する

報告可能な指摘事項には、次のすべてが必要です:

1. 正確なソースの位置。
2. 到達可能なトリガーまたは実行パス。
3. 誤った動作、または違反しているプロジェクト/プラットフォームの契約。
4. ユーザー、データ、セキュリティ、互換性、運用上の具体的な影響。
5. 既存のガード、クリーンアップ、呼び出し元がすでにそれを防いでいないというエビデンス。

報告する前に、候補を反証してみてください:

• 関数全体と関連する呼び出し元/呼び出し先を読みます。
• すべての成功、エラー、キャンセル、終了のパスを確認します。
• 補償的な検証やクリーンアップが他にないか検索します。
• プロジェクトの実際の SDK 範囲における API/デコレーター/パーミッションの動作を確認します。
• 本番コードと、サンプル、生成コード、デッドコード、テストフィクスチャを区別します。

スタイルの好み、根拠のないサイズ制限、一般的な「〜の可能性がある」リスク、影響が示されていないスキャナーの一致は報告しないでください。

5. 影響から重大度を割り当てる

• Critical: 悪用可能なセキュリティ問題、取り返しのつかないデータ損失、またはコアパスにおけるリリースを阻害する障害。
• High: クラッシュ、破損、セキュリティ/プライバシー侵害、またはコア機能の障害が発生する可能性が高いもの。
• Medium: 条件がより限定的な実際の欠陥、回復可能な影響、または重大な機能低下。
• Low: 影響が限定的な軽微で具体的な欠陥。要望がない限り、純粋な見た目の調整は省略します。

重大度は修正の難しさではなく、影響と発生可能性を反映します。

6. まず調査結果を報告する

ユーザーがリポジトリのドキュメントを要求しない限り、会話内で回答してください。完全な Markdown 成果物を要求された場合にのみ、references/report-template.md を使用してください。

調査結果は重大度順に並べてください。各調査結果には以下を含める必要があります:

• [重大度] 簡潔なタイトル
• path/to/file.ets:line
• トリガーと根拠
• 影響
• 焦点を絞った修正案
• 調査結果が HarmonyOS の契約に依存する場合は、公式ソース

根拠の基準を満たす調査結果がない場合は、その旨を明示してください。そのうえで、カバレッジの不足と未実行の検証を別途記載してください。それらを調査結果として膨らませないでください。

終了基準

• スコープと SDK/デバイスの前提が明示されている。
• すべての調査結果がソースに基づいて裏付けられ、独立して対応可能である。
• プラットフォームに関する主張が、プロジェクトのバージョン範囲に対して確認されている。
• 調査結果、未解決の疑問、未検証のリスクが明確に分離されている。
• 実行したテスト/ビルドが正確に報告されている。未実行のチェックは合格と記載されていない。