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に日本語で記載する。ファイルが存在しない場合は新しく作成する。 - •レビューの指摘は以下の形式で記載する。
code
- [重要度] 問題点(1行要約) - `Where` : `path/to/file.rs:line` または `モジュール/関数名` - `What` : 何が読みにくいか（事実） - `Why` : なぜ読みにくいと判断したか（根拠） - `How to fix` : どう直すか(改善方針・コード例など)
- •重要度を以下の3段階で分類する。
- •
Must: 必ず修正が必要な項目 - •
Should: 特別な理由がない限り、修正が必要な項目 - •
May: 修正は任意だが、修正した方がいいと考えられる項目
- •