flutter-code-review

Flutter コードレビュー

動作、ユーザー、リリース、保守性に実質的な影響を与える不具合や実装の残骸を見つけます。レビューは、証拠に基づくリスク評価であり、スタイルの巡回でも、暗黙の書き換えでもありません。

レビュー範囲を定める

1. 対象となる差分、コミット範囲、プルリクエスト、作業ツリー、完了した実装、またはモジュールと、意図された動作を特定します。
2. リポジトリの指示を読み、変更された動作を理解できるよう、関連するコード、テスト、生成コードとの境界、設定を十分に確認します。
3. まず変更行をレビューしますが、証拠から必要と判断される場合は、データフローやライフサイクルを周辺のコンテキストまで追跡します。
4. 単独でレビューを行う場合は、ユーザーから許可されていない限り、ファイルの編集、コメントの投稿、承認、マージ、修正対応への範囲拡大を行いません。許可された実装ワークフロー内では、元の範囲内の問題だけを修正できるよう、指摘事項をそのワークフローに返します。

リスクに基づいてレビューする

データ損失、セキュリティ露出、クラッシュ、誤った結果、ライフサイクルの破綻、並行処理の競合、アクセスできないフロー、リリース失敗、回帰テストの不足、品質ゲートの弱体化、変更によって生じた残骸を優先します。その後、具体的なコストを伴うアーキテクチャまたは保守性の問題を検討します。

好みの問題、仮定上の書き換え、変更されていない既存の問題、現在のコードがすでに処理しているフレームワークの動作は報告しません。API やパッケージに関する主張は、プロジェクトの SDK と解決済みの依存関係に照らして検証します。可能な場合は Dart と Flutter の MCP によるセマンティック検索や分析を使い、そうでない場合はソースと解決済みのパッケージバージョンを直接確認します。

互換性や安全性に関する主張は、証明が必要な要件として扱います。変更された入力、出力、デフォルト、スキーマ、終了時の動作、サポート対象の呼び出し元をベースリビジョンと比較します。古い入力を受け付けるだけでは、後方互換性の証明になりません。マスキング、エスケープ、検証など、セキュリティに関わる変換では、うまくいく例を信頼するのではなく、処理順序と境界条件をテストします。

必要に応じて参考資料を読み込む

• 変更内容の把握、影響の追跡、重大度の調整、指摘事項の形式については、レビューのワークフローを読みます。
• 変更が関係する技術領域に限り、Flutter レビューチェックリストを読みます。

専門分野の変更が実質的な場合や、主張の詳細な検証が必要な場合に限り、該当するスペシャリストを読み込みます。ストレージに関するレビューだからといって、すべての品質スキルが自動的に必要になるわけではありません。

出力

重大度の高い順に指摘事項を先に示します。各指摘には、該当するファイルと範囲を絞った行番号、失敗に至る経路と影響、妥当な修正案を記載します。有用な場合に限り、未解決の質問と短い要約を別のセクションに分けます。

回答する前に、指摘候補を再検討し、重複を取り除きます。ガード、所有権のルール、バージョン制約、テスト、フレームワークの保証によって否定される主張は除外します。指摘の根拠となるのは、問題を導入または顕在化させた最小の変更範囲とします。変更されていないコードを引用する場合は、あくまで補足的な証拠として示します。

対応可能な指摘事項がない場合は、その旨を明確に伝え、重要な検証上の不足を示します。レビューを綿密に見せるために、指摘事項を捏造してはなりません。

完了した実装をレビューする場合は、完了に先立って解決すべき重大な指摘、報告すべき外部または対象範囲外の項目、修正後に再実行すべき限定的なチェックを示し、明確な結論で締めくくります。

参考資料

• Flutter のテスト
• Flutter のパフォーマンス
• Flutter のアーキテクチャ
• Effective Dart
• Dart および Flutter MCP サーバー