code-review

コードレビュー

根拠のある実行可能な指摘、または妥当な問題なしの判定を含む、範囲を限定したレビューを1件実施します。実装、システム、設計、ダイエットの各観点を適切な比重で適用します。推測に基づく指摘をするくらいなら、指摘しないほうが望ましいです。

範囲とガイダンス

指定されたファイル、サブシステム、ブランチ、コミット、PR、または差分を対象にします。ロードマップ、仕様書、課題、ADR、移行に関するレビューでは、文書だけでなく、その文書が規定する実装も確認します。意図する成果、主張されているマイルストーン、実装範囲、編集方針を確認します。対象が指定されていない場合、未コミットの変更があればそれを対象にします。対象を推定できない場合に限り、確認を求めます。

中核となるレビューと安全な修正の方針については、実装の観点を参照してください。対象に関係する場合は、ほかの詳細な観点も確認します。

• システム：取り組みの実施、技術的な選択、または横断的な影響を確認します。要求された成果が実際に実現されているかを確認します。
• 設計：変更された責務、インターフェース、依存関係、または利用者を確認します。契約と不変条件に明確な責任者がいるかを確認します。
• ダイエット：追加された概念、状態、ラッパー、互換性対応パス、その他の複雑さを確認します。追加された仕組みが、その保守コストに見合っているかを確認します。

通常のローカルな編集であれば、すべての観点を読み込んだり、リポジトリ全体の監査に広げたりせず、簡潔に確認できます。影響を受ける要件と利用者の経路をたどり、新たに生じた問題と既存の負債を切り分けます。

指摘と修正

各問題は、修正すべき場所に一度だけ記録します。発生条件、影響を受ける経路または規定要件、結果、根拠、想定される対応を示します。設計上の好みや仮定上の柔軟性は指摘事項ではありません。

• 区分 I — 安全な修正： 範囲内で限定的かつ機械的に検証でき、プロダクト、設計、展開、互換性、リスクに関する未解決の判断を伴わない変更です。ユーザーがレビューのみを求めている場合を除き、原則として適用します。その場合は提案として明記します。
• 区分 II — 判断が必要： トレードオフや決定権者が未確定である、実際の問題です。実行可能な最小限の代替案と、必要な判断を説明します。すでに提示されている判断は、許可された範囲内で適用します。未解決の点が残る場合に限り、確認を求めます。

根拠のある問題が解決するか、具体的な制約によって続行できなくなるまで、修正と影響を受ける検証を再確認します。レビューを自律的な反復ループにしたり、新たな根拠なしに合格済みの確認を繰り返したりしないでください。依頼がない限り、ステージング、コミット、プッシュは行いません。

報告

影響の大きい指摘を、適用済みか提案かを明記して先に示します。取り組みのレビューでは、成果の達成状況も含めます。また、検証内容と重要な残存リスク、必要に応じて、意図的に変更しないと判断した重要事項も記載します。問題がないレビューでは、空の区分やチェックリストの記録は不要です。結果と検証上の限界だけを示します。