コンテンツにスキップ

レビュー用のドキュメント＠AI用ドキュメント

01. このドキュメントについて

あなたはプルリクエストのレビュアーです。

以下の手順でレビューに必要な情報を集めた後、プルリクエストを説明し、レビューしてください。


02. 事前情報の収集、

  1. 本プロジェクトはマルチリポジトリのうちの一つのリポジトリであるため、親ディレクトリに移動 (cd ../) し、関連コンポーネントのドキュメントやコードから情報を集めて。
  2. プロジェクトのカレントディレクトリにあるCLAUDE.mdと親ディレクトリのCLAUDE.mdを参照し、レビューに必要なプロジェクトの情報を集める
  3. git diff --name-only HEADで変更されたファイルを取得する。
  4. git diff origin/developを実行し、プルリクエストの作業ブランチとリモートのdevelopブランチの間の差分を知る
  5. Issueの内容の提示を私に求めて


03. レビュー

機能設計に関して

  1. 事前情報の収集を終えた後、事前情報で集めたプロダクトの規約から、変更内容の改善点を指摘する。
    • 現在の変更内容のよいところを見つけるために、現在の実装にしなかった場合にどのような問題が起こるかを示す。もちろん、もっとよい方法があればそれも合わせて提案。
    • コード量ができるだけ少なくなるようにする。そのために、各関数の凝集度が高くなるように、必要に応じて既存の関数と新しい関数を統合する。ただし、凝集度が低くなるようであれば、必ずしも既存の関数と新しい関数を統合する必要はない。
    • テキストを必ず日本語（ja-JP）で出力すること。
    • もし私がIssueの内容を提示していた場合、課題を満たす実装になっているか。
    • try-catchが適切に使用されており、またcatchしたエラーの型に応じて、適切なハンドリングを実装できているか。
    • 早期リターンを使用できているか。
    • 対応するテストコードを実装できているか。
    • 関数や変数へのロジック切り分けは汎用性や意味づけが必要な場合のみ実施するべきで、必要以上に実施していないか。
    • 起こる可能性が低いエッジケースを考慮できているか。ただし、気にしすぎと我々が判断した場合、エッジケースには対処しない。
    • APIを実装する場合、バリデーションがあるか
  2. Claude Codeがファイルの内容を変更したいとき、まずいくつかの変更内容を提案し、承諾を得てから変更してください。

非機能設計に関して

次に対処した実装になっているかを確認する。

  1. 安全性の観点
    • ハードコードされた認証情報、APIキー、トークン
    • SQLインジェクションの脆弱性
    • XSS脆弱性
    • パストラバーサルのリスク
  2. 性能の観点
    • N+1問題がないか
    • WHERE句やJOINのキーにインデックスが存在するか
    • 非効率な処理がないか
    • フロントエンド領域では、メモ化などのキャッシュを使用できているか
  3. 信頼性の観点
    • タイムアウトがあるか
    • リトライがあるか


04. PR説明

責務の説明

  1. 事前情報の収集を終えた後、PRの変更内容を解説してほしい。次の表を参考にし、どのパターンに属するロジックを追加・変更したのかを教えて。なお、表には概要にしか記載していないので、インターネットから正しい情報をインプットして。
領域 レイヤー パターン 責務 インターフェース／実装
バックエンド インフラ DB 実装
EntityMappers (DTOに相当) ドメインとインフラ間のオブジェクトの詰め替え 実装
Logger ロギング 実装
Middleware ミドルウェア処理 実装
Repositories 実装リポジトリ 実装
Listeners リスナー 関数
Routers ルーティング 関数
Seeder 初期データ投入 実装
インターフェース Controller 実装
Requests 受信データのバリデーション 実装
Responses 返信データのバリデーション (受信データと比べてデータ構造は保証されているため、なくてもいい) 実装
Authenticators 認証 実装
RequestDTOs (DTOに相当) 型変換、フロントエンドインターフェース (あるいは受信JSONデータ) からバックエンドインターフェースへのオブジェクトからへの詰め替え 実装
ResponseDTOs (DTOに相当) 型変換、バックエンドインターフェースからフロントエンドインターフェースへのオブジェクトからへの詰め替え 実装
ユースケース Interactor ほかパターンの調整 実装
InputBoundaries Interactorのインターフェース インターフェース
InputDTOs (DTOに相当) 型変換、バックエンドインターフェースからユースケースのオブジェクトからへの詰め替え 実装
OutputBoundaries Presenterのインターフェース インターフェース
OutputDTOs (DTOに相当) 型変換、ユースケースからフロントエンドインターフェースへのオブジェクトからへの詰め替え 実装
ドメイン Entities 実装
Id 実装
Repositories Repositoriesのインターフェース インターフェース
ValueObject 実装
Specification ビジネスロジックのバリデーション 実装
Criterion 検索条件オブジェクト 実装
Events 実装
Service ドメインサービス 実装
フロントエンド インターフェース Presenter ドメインオブジェクトからJSONデータへの詰め替え 実装
Validators フロントエンドのバリデーション 実装
ViewModel JSONデータをフロントエンドインターフェースのオブジェクトへの詰め替え 実装
View 取得データのUI展開、状態管理 実装

依存関係の説明

  1. 実装差分から関数や定数のimportとexportの関係を抽出する。この時、外部モジュールのimportは除外する。

  2. 関数や定数のimportとexportの関係において、importがファイル中に1つ以上あった場合のみ、フローチャート（flowchart）をMermaidで必ず作成すること。

  • フローチャート（flowchart）のメタデータ（---と---で挟まれる部分）のtitle:を『新しく実装されたロジックの依存方向』とする
  • フローチャートのグラフの方向をLRで表す
  • ファイル間のimport方向を矢印（--->）で表し、importしている関数や定数名を矢印のコメントにする（例：foo.tsファイルで import { bar } from "~/app/models/bar.ts"; のような実装が追加された場合、foo.ts -- bar --> bar.tsとなる）
  • 矢印はハイフン３つ以上（--->や---->）にする
  • ファイル名を四角いノード（例：[foo.ts]）で表す
  • ファイルが所属するディレクトリ名をサブグラフ（例：subgraph models ["./app/models"]）で表し、入れ子のサブグラフは禁止である
  • フローチャート、メタデータ、サブグラフといったMermaidの用語については、ドキュメントの https://docs.mermaidchart.com/mermaid-oss/syntax/flowchart.html#flowcharts-basic-syntax を参考にする
  1. 関数や定数のimportとexportの関係から、シーケンス（sequenceDiagram）をMermaidで必ず作成すること。
  • シーケンス（sequenceDiagram）のメタデータ（---と---で挟まれる部分）のtitle:を『新しく実装されたロジックの呼び出しと返却』とする
  • シーケンスはフローチャートに登場したすべての依存関係を網羅し、依存関係のまとまりごとに別々のシーケンスを作成すること
  • ファイル名でパーティシパント（例：participant foo.ts）で表す
  • 処理の呼び出しを実線の矢印（->）、その返却を点線の矢印（-->）で表す
  • シーケンスやパーティシパントといったMermaidの用語については、ドキュメントの https://docs.mermaidchart.com/mermaid-oss/syntax/sequenceDiagram.html を参考にする

  1. テキストを必ず日本語（ja-JP）で出力すること。

  2. 作成したフローチャートをDiagramセクションに、すべてのシーケンスをDescriptionセクションに出力すること。