code-review

コードレビューのワークフロー

コードを変更したり、外部にレビューを公開したりせずに変更をレビューします。ユーザーの言語で回答してください。対象が明確であればすぐにレビューを開始し、曖昧さによって範囲や意図が大きく変わる場合に限り、質問してください。

1. 対象とバージョンを特定する

差分を取得する前に、Git operationsを読んでください。指定された範囲、特定したコミット ID またはインデックス／作業ツリーの状態、比較ベース、およびパス制限を記録してください。

• 対象が指定されていない場合：ステージ済み、未ステージ、および未追跡の変更を含めます。変更がない場合は、何をレビューするか尋ねてください。HEAD で代用しないでください。
• ステージ済みのレビューが明示されている場合：変更内容と周辺の呼び出し元の両方について、変更されていないファイルも含め、インデックスの内容を使用してください。
• コミットまたは範囲が指定されている場合：コンテキストと利用箇所の確認には指定されたリビジョンを使用し、そのリビジョンの動作を示す根拠として現在の作業ツリーファイルを使用しないでください。
• ファイルパスによって対象が絞られている場合：指摘事項はそのパスに限定し、コンテキスト把握に必要な利用箇所は境界外も確認してください。対象範囲の境界を明記してください。
• エンドポイント間の比較、マージベースとの比較、および従来の包括的な start~end 表記を区別してください。コマンドを成功させるために比較ベースを黙って変更しないでください。

未解決の競合がないかステータスを確認し、ルートコミットとマージを明示的に扱ってください。ユーザーのインデックスと作業ツリーを保持してください。

2. 変更を洗い出し、意図された動作を説明する

選択したバージョンの要件、関連する契約、および変更前後のコードを読みます。どの入力がどのような観測可能な結果をもたらすべきかを明らかにしてください。コミットメッセージはコンテキストであり、正しさの証明ではありません。

変更されたファイルごとに、レビュー済み、理由を添えて機械的に確認済み、または未レビューのいずれかとして記録してください。ソースをファイル数だけで判断して抜き取るのではなく、動作への影響を優先してください。生成物、ロックファイル、ベンダーコード、バンドルは、実際のデプロイや依存関係への影響に応じて確認してください。ファイル名だけを根拠に、内容が無関係だと判断してはいけません。必要に応じて、ジェネレーターと出力を併せて確認してください。レビューを完了できない場合は、確認を省略した範囲を明記してください。

3. 利用箇所をたどって動作を確認する

impact detectionを読んでください。呼び出し元 → 中間レイヤー／共有抽象化 → 最終利用箇所の順にたどります。引数、デフォルト値、設定、戻り値、エラー、キャンセルシグナルが、変換や優先順位の規則を通じてどのように伝わるかを確認してください。変更された値が実際の実行時動作に影響することを確かめてください。

公開エクスポート、アダプター、シリアライズされたデータ、動的登録、および確認可能な場合は外部の利用者も調べてください。検索結果は候補となる経路を示すものです。結論を出す前に、それらの経路を確認してください。過去のバージョンやインデックスをレビューする場合は、バージョンを考慮した検索または分離されたスナップショットを使用してください。

4. 関連する実用的な確認を行う

review checksを読み、変更範囲に適した確認項目を選んでください。関連する場合は、境界条件、認可、状態遷移、並行処理、リソースのライフタイム、リトライ／冪等性、互換性、コスト、テストのアサーションを調べてください。レポートで参考資料を必須のチェックリストとして扱わないでください。

保守性は別途評価してください。現存する複雑さ、重複したポリシー、結合を特定し、局所的な改善によって得られる具体的な利点を説明してください。個人的なスタイル上の好みや、推測に基づく抽象化は、原則として除外してください。

5. 疑わしい不具合を一つずつ検証する

報告する前に、実行可能なトリガー、実行経路、期待される動作と実際の動作、コード上の根拠、および影響を確認してください。反証となる要素も探してください。たとえば、呼び出し元での検証、互換性レイヤー、意図された要件、クリーンアップ／フォールバック処理、または実行時保証です。

ベースバージョンと比較し、この変更で新たに生じたものでも悪化したものでもない既存の問題は除外してください。根本原因が同じ報告は、複数のファイルや利用箇所に現れていても統合してください。実行による再現がなくても、静的な根拠によって不具合を示せる場合があります。その場合は、どの種類の根拠が裏付けとなっているかを明記してください。ある事実が不明なために主張が覆る可能性がある場合は、確認済みの不具合として提示せず、制約事項の下に検証の質問として記載してください。

6. 分類して報告する

出力形式を読みます。実際の影響と発生条件に基づいて不具合の重大度を判断します。深刻なセキュリティ／データ／可用性への影響がある場合は Critical、重大な誤動作がある場合は Major、影響が限定的で小さい場合は Minor とします。不確実性は分けて記載します。確信度スコアを計算したり、テストがないことや利用者が多いことを理由に重大度を引き上げたりしないでください。

既定の順序は、対象、不具合（重要度順）、保守性に関する所見、検証と制約です。確認済みの不具合がない場合は、その旨を明記してください。任意のセクションに該当する内容がなければ省略し、儀礼的な称賛は避けてください。ユーザーが判定を求めた場合に限り、出力リファレンスにある定性的な判断基準を適用してください。指摘件数や加重スコアは決して使用しないでください。

ツールと境界

Git と利用可能なリポジトリのナビゲーションツールを使用します。利用可能で適切な場合は、codemap-search を優先してください。関連するパスとファイル形式を検索します。現在のワークツリーのナビゲーションインデックスは、過去の内容やステージ済みの内容を示す証拠にはなりません。その場合は、Git の BLOB／検索機能、または一致する隔離済みスナップショットを使用してください。許可されており、関連性がある場合は、既存の検証コマンドを実行し、正確なコマンド、実行場所、結果を報告してください。レビューの依頼だけでは、ソースの変更、新しいテストの追加、外部への投稿は許可されません。

アーカイブされた文字どおりの例

以下の保持されたブロックは過去の例であり、実行する手順ではありません。上記の現在のワークフローを使用してください。単一コミットの show の例には、上記のルート／マージの処理が必要です。包括的な範囲指定コマンドには、有効な親が必要です。マージベースコマンドは、共通祖先を明示的に比較するよう求められた場合にのみ適用し、代替手段として使用しないでください。ワークツリーの rg の例に、過去またはインデックスのコンテキストを与えてはいけません。

git --no-pager show --stat <commit_hash>
# or for staged changes:
git --no-pager diff --cached --stat

# Single commit
git --no-pager show <commit_hash>

# Staged changes
git --no-pager diff --cached

# Commit range
git --no-pager diff <start_hash>^..<end_hash>

# File-scoped
git --no-pager show <commit_hash> -- <file_path>

# Find direct callers
rg -F "symbolName(" .
# Find broader references
rg "symbolName" .