コードレビューで最初に見る意図・契約・リスク

レビューでは、インデントや変数名より先に「この変更によって、利用者に何が起きるか」を確認します。目的と危険を理解してからコードを読みます。

今回やること

Code Reviewで目的と成功条件、入出力契約、失敗と再試行、認証・認可、Dataと同時実行、Test根拠を確認してから命名と読みやすさを見る図

次の順で差分を確認します。

通信失敗時に申込を再送する変更をレビューするとします。目的は「失敗を減らす」だけでは足りません。「最初の保存後に応答が失われても、同じ申込が二件できない」が成功条件です。

次の質問で契約を確認します。

同じ申込キーで再送した時、既存の結果を返しますか？
400や403も再送していませんか？
保存に成功した後の通知は二重になりませんか？
誰がこのAPIを呼べますか？

クライアントの再送ループだけでなく、サーバーの一意制約、通知処理、既存のテストも見ます。変更行の外にある契約が壊れていないかを確認するのがレビューです。

「冪等性が心配です」だけでは、作者が次に何をすればよいか分かりません。

最初のPOSTが保存後にtimeoutした場合、同じキーの再送で
二件作成されない契約でしょうか。
同一キーの統合テスト、またはDBの一意制約で確認したいです。

条件・影響・必要な証拠を添えます。必ず直す不具合、仕様の質問、任意の改善は分けて伝えると、優先順位も明確になります。

承認する前に、目的に対する代表的な成功と失敗を確認します。再送の例なら、通常の一回、同じ入力の再送、権限のない利用者、保存後の応答喪失を分けます。statusだけでなく、作成件数と通知回数も見るのがポイントです。

レビューの最後に「どのリスクを、どのテストまたは制約で確認したか」を短く残すと、後から判断をたどれます。

表示を隠してもAPIを直接呼べる場合があります。ルート、サービス、対象データの所有者条件まで確認します。

成功statusだけを確認するテストでは、保存が二重になったことや副作用が増えたことを見逃します。assertしている値まで読みます。

メールアドレス変更の差分を想像し、本人確認、重複、確認リンクの期限、古いログインID、並行した変更要求について、それぞれ一つずつレビュー質問を書いてください。