コンテンツにスキップ

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

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

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

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


02. 事前情報の収集

次の番号の手順で事前情報を収集する。

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


03. PRの説明

戦略的設計の観点

PRはドメイン駆動設計の戦略的設計に基づいて説明して。要望は後述の通り。

  • ドメインエキスパートが誰かを仮定して
  • ユースケース図を作成して
  • オブジェクト図を作成して

戦術的設計の観点

PRはドメイン駆動設計の戦術的設計に基づいて説明して。要望は後述の通り。

次の戦術的設計表を参照し、どのパターンを実装しているか。どのパターンに属するロジックを追加・変更したのかを教えて。

表には概要にしか記載していないので、インターネットから正しい情報をインプットして。

バックエンドレイヤー パターン 責務 インターフェース／実装
インフラストラクチャ層 DB データベースとの接続、コネクションの作成 実装
EntityMappers (DTOに相当) ドメインとインフラ間のオブジェクトの詰め替え 実装
Logger ロギング 実装
Middleware ミドルウェアパターン 実装
Repositories 実装リポジトリ 実装
Listeners リスナー 関数
Routers ルーティング 関数
Seeder 開発環境、CI環境のユニットテストやE2Eテスト、ステージング環境の動作確認に使用する初期データ挿入 実装
Drivers SDK、ORM、CLIなど 実装
プレゼンテーション層 Controller データの受信と返信 実装
RequestValidators 受信データのバリデーション 実装
ResponseValidators 返信データのバリデーション (受信データと比べてデータ構造は保証されているため、なくてもいい) 実装
Authenticators 認証 実装
InputAdapter 型変換、入力データ翻訳、フロントエンドインターフェース (あるいは受信JSONデータ) からバックエンドインターフェースへのオブジェクトからへの詰め替え 実装
OutputAdapter 型変換、出力データ翻訳、バックエンドインターフェースからフロントエンドインターフェースへのオブジェクトからへの詰め替え 実装
ユースケース層 Interactor ドメイン層で定義されたビジネスルールを組み合わせ、ユースケースを具現化する。 実装
InputBoundaries Interactorのインターフェース インターフェース
InputDTOs (DTOに相当) 型変換、バックエンドインターフェースからユースケースのオブジェクトからへの詰め替え 実装
OutputBoundaries Presenterのインターフェース インターフェース
OutputDTOs (DTOに相当) 型変換、ユースケースからフロントエンドインターフェースへのオブジェクトからへの詰め替え 実装
Repositories（Gatewaysとも呼ぶ） Repositoriesのインターフェース インターフェース
ドメイン層 Entity ドメインモデル、ビジネスルールの定義 実装
Id ドメインモデルの識別子 実装
ValueObject 値オブジェクト 実装
Specification ビジネスロジックのバリデーション 実装
Criterion 検索条件オブジェクト 実装
Events ドメインイベント 実装
Service ドメインサービス 実装
フロントエンドレイヤー パターン 責務 インターフェース／実装
プレゼンテーション層 Presenter ドメインオブジェクトからJSONデータへの詰め替え 実装
Validators フロントエンドのバリデーション 実装
ViewModel 状態管理、JSONデータをフロントエンドインターフェースのオブジェクトへの詰め替え 実装
UI層 View UIレンダリング、CSSスタイリング 実装


04. レビュー

事前情報の収集を終えた後、事前情報で集めたプロダクトの規約から、変更内容の改善点を指摘する。

レビュー方針

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

  • 現在の変更内容のよいところを見つけるために、現在の実装にしなかった場合にどのような問題が起こるかを示す。もちろん、もっとよい方法があればそれも合わせて提案。
  • テキストを必ず日本語（ja-JP）で出力すること。

機能設計に関して

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

  • 機能設計がGitHub Issueの課題を満たす実装になっているか
  • バックエンドの観点
    • ユーザーのユースケースを満たすCRUDを実装できているか
    • モデルやDBのデータ型は適切か
    • ビジネスロジックがドメイン層以外に流出していないか
  • フロントエンドの観点
    • ユースケースを満たすUIを実装できているか

非機能設計に関して

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

  1. 安全性の観点
    • ハードコードされた認証情報、APIキー、トークン
    • SQLインジェクションの脆弱性
    • XSS脆弱性
    • パストラバーサルのリスク
  2. 性能の観点
    • N+1問題がないか
    • WHERE句やJOINのキーにインデックスが存在するか
    • 非効率な処理がないか
    • フロントエンド領域では、メモ化などのキャッシュを使用できているか
    • ループ内で線形探索処理を実行してしまっていないか
    • ページネーションを使用せずに、大量のデータ量を取得して一ページに表示していないか
  3. 信頼性の観点
    • タイムアウトがあるか
    • リトライがあるか
  4. 保守性の観点
    • バックエンド（すべての領域）、フロントエンド（Presener、Validators、ViewModelの領域のみ）の観点
    • try-catchが適切に使用されており、またcatchしたエラーの型に応じて、適切なハンドリングを実装できているか。
    • 早期リターンを使用できているか。
    • 関数や変数へのロジック切り分けは汎用性や意味づけが必要な場合のみ実施するべきで、必要以上に実施していないか。
    • 起こる可能性が低いエッジケースを考慮できているか。ただし、気にしすぎと我々が判断した場合、エッジケースには対処しない。
    • APIを実装する場合、バリデーションがあるか
    • 型推論が可能な言語では、型定義は必要最低限で問題ない。最低限の型定義になっているか。
    • 既存の関数を使用すれば少ないロジックで済むのに、それを使用せずに再発明してしまっていないか
    • コードの変更行ができるだけ少なくなるように提案する。そのために、各関数の凝集度が高くなるように、必要に応じて既存の関数と新しい関数を統合する。ただし、凝集度が低くなるようであれば、必ずしも既存の関数と新しい関数を統合する必要はない。
    • 使用する文字列値、数値、配列を定数として切り分けられているか
      • カラーコード：{info:"#10B981",error:"#EF4444"}
      • ソートバイモード：name、type
      • ソートオーダーモード：asc、desc
      • フィルターモード：OR、AND
      • UI閲覧モード：group、list、panel
      • なんらかのタグ名：タグ名なし
      • レスポンスコード：200、404
      • 時間範囲：{id:"1d",value:1,label:"前日"}}
    • フロントエンド（View）の観点
      • ViewModelから取得したデータを適切にUIに展開できているか
      • 変更したUIは特定のユースケース時のみ表示されるようになっているか
      • 変更したUIがほかViewに影響を与えていないか
      • コンポーネントへのロジック切り分けは汎用性や意味づけが必要な場合のみ実施するべきで、必要以上に実施していないか。
      • エラー発生時にUIの表示は崩れないか
      • 既存のコンポーネントを使用すれば少ないロジックで済むのに、それを使用せずに再発明してしまっていないか

テスト設計に関して

  1. バックエンド、フロントエンド（Presener、Validators、ViewModelのみ）の観点
    • 適切なテストスイート設計になっているか
      • describe("<パブリックな関数名") > describe("<テストスイート種別") > it("<正常系または異常系のテストケース>")
    • 必要なテストコードを実装できているか
    • 正常系のテストが冗長ではないか（ほかの正常系で検証できていることを再度検証している）
    • UIバリデーションやDBカラム型によって、起こり得ない入力値をテストしてしまっていないか
    • 正常系と異常系のそれぞれで境界値分析を実施できているか
  2. フロントエンド（View）の観点
    • E2Eテストがあるか

修正依頼提示のための修正サンプル

Claude Codeがファイルの内容を変更したいとき、まずいくつかの変更内容を提案し、承諾を得てから変更してください。


05. 依存関係の説明

  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セクションに出力すること。