FLINTERS BLOG
👨‍💻

AIによる一次レビューのすすめ:レビュー指針を文書化してチーム開発を加速しよう

に公開

AIを使って1次レビューすることで、人間のレビュワーの余分な手間を減らせます。

Visual Studio Code の Copilot Agent を使います。

プロジェクトの .github/prompts/review.prompt.md に以下のファイルを置きます。
レビューの観点はプロジェクトによって変えます。

# GitHub Copilot による code review

`git --no-pager diff $(git merge-base origin/main HEAD)` を実行して、差分をレビューします。

改善したほうが良い点については、重要度を高・中・低の3段階で評価し、重要度が高いものから順に具体的なコード例を挙げて説明します。

最後に簡潔な総合的評価を行います。

重要な改善点に対してCopilotによる修正が可能と考えられる場合には、一度ユーザーに尋ねたうえで修正を試みます。

## レビューの観点

- コードの可読性
  - コードは簡潔で他人が読んでも理解しやすいか?
  - コメントは適切に書かれているか?
  - 命名規則は一貫しているか?
  - typo はないか?
  - 実装内容とクラス名やメソッド名が一致しているか?
- 保守性・拡張性
  - 変更や機能追加が容易な構造になっているか?
  - ハードコーディングやマジックナンバーが避けられているか?
- テスト
  - テストしやすい設計になっているか?
  - 必要十分なテストは書かれているか?
  - mockが多すぎるなど、保守が難しいテストを書いていないか?
- セキュリティ
  - SQL injection, command injection, XSS などよく知られた脆弱性はないか?
- ライブラリ
  - Scala 標準の Future より ZIO を優先する
  - 例外はなるべく使わず ZIO の E を使う
  - ZIOのコードではClockを constructor injection せずに ZIOのClockを使う
- DDD
  - ドメインモデルは適切に分離されているか?
  - ユビキタス言語が使われているか?(言葉の揺れがないか?)
- パフォーマンス
  - 不要な計算や重複処理がないか?
  - 大量データ処理時の効率性は考慮されているか?
- ドキュメント
  - 関数やクラスの用途・引数・戻り値が明確に記載されているか?
  - GraphQL API を変更した場合は SDL のコメントは十分に記載されているか?

Copilot agent の入力エリアに /review と入力し Enter を押します。
すると review.prompt.md の内容が実行されます。

チーム内での方向性を文面にしたためておくことで、ある程度方向を揃えることができます。
AI のことですので完璧ではないことに注意は必要です。

現状(2025-05-15 時点)の私の所感では Claude 3.7 Sonnet が最もマトモなレビューをしてくれます。

AIが働きやすい環境というのは人間にとっても働きやすい環境なのではないか、ということを最近思うようになりました。
このようなガイドラインを明文化することにより、AIはもとよりチームメンバーも理解を深めることができます。

Happy Copilot!

FLINTERS BLOG
FLINTERS BLOG

Discussion