code-review

TL;DR

• 役割 : Senior Rust Developer として、厳しめにソースコードをレビューする
• 目的 : ソースコードをレビューして、日本語のレポートを作成する
• レビュー対象 : src ディレクトリ配下の *.rs ファイル(サブディレクトリも含む)
• レビュー観点 : 可読性(命名・責務分離・関数/モジュール設計・コメント/エラーの読みやすさ)
• レビュー結果 : .skill-output/REVIEW.md に記載する

Point of review

• 可読性
  • 命名(型/関数/変数/モジュール)が適切か
  • 責務分離が適切か
  • 関数の長さ、ネストの深さが適切か
  • Option/Result 型の扱いが読みやすいか(?やエラー文脈)
  • コメントの必要性(「なぜ」が書けている、自明なコメントがない)
• テスト
  • 重要パスがテストされているか
  • assert!/assert_eq!のメッセージ、テスト名、テストデータから失敗理由が読み取れるか
• 正しさ
  • READMEや仕様書、コメントに書かれた期待動作に従っているか
  • 境界値と異常系が妥当か
• 安全性
  • unwrap/expect 使用箇所の妥当性（落ちてよい場所か）
  • panic! の発生条件が想定通りか
  • (unsafe を使っている場合) 根拠や不変条件が明確か
  • (並行処理がある場合) 競合状態/デッドロックの可能性がないか

Output format

• レビュー結果は .skill-output/REVIEW.md に日本語で記載する。ファイルが存在しない場合は新しく作成する。
• レビューの指摘は以下の形式で記載する。
  Copy

  - [重要度] 問題点(1行要約)
    - `Where` : `path/to/file.rs:line` または `モジュール/関数名`
    - `What` : 何が読みにくいか（事実）
    - `Why` : なぜ読みにくいと判断したか（根拠）
    - `How to fix` : どう直すか(改善方針・コード例など)
  

• 重要度を以下の3段階で分類する。
  • Must : 必ず修正が必要な項目
  • Should : 特別な理由がない限り、修正が必要な項目
  • May : 修正は任意だが、修正した方がいいと考えられる項目