コードレビュー
バグ、セキュリティ、性能の問題につながる箇所だけを挙げる
あなたはシニアエンジニアです。次のコードをレビューし、バグ、セキュリティ問題、性能問題につながる箇所だけを重大度順に指摘してください。各項目について：1）何が問題か；2）どんな条件で発現するか；3）具体的な修正方法。コードスタイルには触れず、「コメントを追加してはどうか」といった指摘も不要です。 ``` ［コードを貼り付けてください］ ```
使い方
修正案を書かせる前に、各指摘の重大度を採点させましょう。低く採点した項目は、たいてい推測で挙げたものです。
向いている場面
- 変更が動作する状態になり、PR を出す直前です。同僚のレビューより先に、壊れる箇所を見つけておきたいとき。
- テストのない古いコードを引き継ぎ、手を入れる前に危険な箇所を知りたいとき。
向いていない場面
- まだコードが動かず、何をしたいのかも説明できない段階です。まず動かしてからレビューします。
- 命名やインデントを揃えたいだけなら、linter や formatter のほうが確実です。
例
入力
@app.route("/orders/<int:user_id>")
def orders(user_id):
rows = db.execute(f"SELECT * FROM orders WHERE user_id = {user_id}")
result = []
for r in rows:
item = requests.get(f"https://api.internal/items/{r['item_id']}").json()
result.append({**r, "item_name": item["name"]})
return jsonify(result)得られるもの
まず f-string で SQL を組み立てている箇所のインジェクション（user_id に `0 OR 1=1` を渡すと回避できます）を挙げ、次にループ内の HTTP 呼び出しによる N+1 とタイムアウトの欠如、最後にページングの欠如を挙げます。各項目には発現条件と具体的な修正方法（プレースホルダ化、IN でまとめて取得、timeout の追加）を付け、命名や書式には触れないようにします。
よくある誤用
- 800 行を一度に貼って「どこが問題か見てください」とだけ頼むと、注意が全行に均等に配られ、本当に壊れる 1 行が十数件のスタイル指摘に埋もれます。
- 実行環境（Python のバージョン、スレッドの有無、データ量）を伝えないと、最も一般的な前提でレビューされ、こちらには存在しない問題が報告されます。
こう変えると効く
- 「データ破損やセキュリティにつながるものだけ。見つからなければそう言ってください」と加えると、数を埋めるための指摘が明確に減ります。
- 「重大度順」を「各項目で、まず発現する入力を示し、その後に修正を示す」に変えると、結論だけでなく再現できる根拠が返ってきます。