先日書いたプロジェクトルールの実装例の続きです。

miyohide.hatenablog.com

前回書いたプロジェクトルールを数日間試してみたのですが、あまりよい流れとならなかったので再度練り直しました。結果として、以下のような形になりました。

# 基本

- 日本語で応答してください
- 必要に応じて、ユーザに質問を行い要求を明確にしてください
- GitHubへアクセスが必要な場合は、GitHub CLIの`gh`コマンドを使ってください

# 作業の定義

それぞれの作業を以下のように定義します。

- 「設計」と指示された場合、指示されたことに対して以下のことを実施してください
    - GitHubにIssueを作成してください。Issueのタイトルは指示された内容を30文字以内にまとめたもの、Issueの内容は指示されたものとしてください。
    - `docs/designs` に `YYYYMMDD-GitHubのIssueの番号-design.md` という名前のファイルを作成し、記載してください
        - ファイル名の中にある`YYYYMMDD`は`date`コマンドなどを使って現在の日付を正しく取得するようにしてください
    - この段階でコードは絶対に書かないようにしてください
    - この段階では、指示されたことに対してAPIエンドポイント設計やテーブル設計、作成・更新が必要なコードについて考えファイルに出力してください。
- 「実装」と指示された場合、以下のことを実施してください。
    - 同時に指示された`docs/designs`内の`YYYYMMDD-GitHubのIssueの番号-design.md`という名前のファイルの内容をGitHub Issueのコメントとして追加してください
    - GitHub Issueの番号を使って、`feature/GitHubのIssueの番号`というgitのブランチを作成してswitchしてください。このとき、`develop`ブランチを親ブランチとします
    - 指示された内容に基づいてコードを書いてください
    - コードを書き終えたらコミットしてください
- 「実装レビュー」と指示された場合、以下のことを実施してください
    - ブランチ`feature/GitHubのIssueの番号`をGitHubにpushしてください
    - ブランチ`feature/GitHubのIssueの番号`を使ってPull Requestを作成してください。このとき、マージ対象のブランチは`develop`としてください

# `docs`ディレクトリの内容

- `docs/designs/*.md` : 設計資料

# ブランチ戦略

このプロジェクトのブランチ戦略はGitflowを用います。それぞれのブランチの意味は以下の通りです。

- `main` : 本番環境にデプロイされているブランチ
- `develop` : 次のリリースに向けた開発が行われているブランチ
- `feature/*` : 新機能の開発が行われているブランチ
- `release/*` : リリース準備が行われているブランチ
- `hotfix/*` : 本番環境で発生したバグ修正

考え方としては以下の通りです。

設計作業を実施。Issueに紐付け。設計内容を手元のMarkdownファイルにも保存（AmazonQで実施）
設計内容を人の目で確認。必要であれば修正を行う
Markdownファイルの内容をもとに実装。Issueも合わせて更新（AmazonQで実施）
必要であれば人の手で修正。
Pull Requestを作成してレビュー依頼（AmazonQで実施）

あわせてGitのブランチ戦略も必要かと思い、ここではGitFlowを採用しました。GitFlow自身の細かい説明は実施せず、ブランチの内容を補足したぐらいで概ねうまく動いてくれています。

また、GitHub CLIであるghコマンドも詳細を教えなくてもうまく動いてくれます。生成AIにおいては広く使われて、ドキュメントがオープンになってしっかり書かれているもののほうが挙動は安定するかと感じます。

動かした結果例は以下の画像を参照してください。

ちなみに、AmazonQがgradlewコマンドをうまく動かすことができず、bashコマンドを使っているのがちょっとよくわからない。

その他

あとは細かいコーディング規約を追加しました。まだテーブル設計までは試し切れていませんが、こんなものを作ろうと考えています。

プロジェクト内でSQLのコーディングを行う際は下記ルールに従ってください。

# 命名規則

- 予約後（`SELECT`、`FROM`、`WHERE`など）は大文字で記述します
- テーブル名、カラム名、ビュー名などのオブジェクト名は小文字で記述します
- 複数の単語からなる名前は、スネークケース（`_`で連結）を使用します
- テーブル名は、そのテーブルが保持するエンティティの複数形を使用します。例えば`users`や`products`などです。
- カラム名はそのカラムの情報を明確に表す単数形を使用します

# コメント

- テーブルやカラムにはコメントを付与するようにしてください

# 禁止事項

- `SELECT *`は使用しないでください
    - 不要なデータを取得してしまい、パフォーマンスの低下を招く恐れがあるためです。また、スキーマ変更時に予期せぬ挙動を引き起こす可能性があります

# 使用するデータ型

- 文字列データには`VARCHAR`を使用してください。このとき、必ず長さを指定してください。
- できる限りNOT NULL制約をつけてください。
- 日付と時刻のデータにはタイムゾーンが保存できる型を使用してください

これはまだ未検証なので、どこまで意図した通りになるか楽しみです。

miyohide's blog

Amazon Q developerにおけるプロジェクトルールの実装例その2

その他