Gemini Code Assist にプルリク上で DDL をレビューさせる

Gemini Code Assist に DDL をレビューさせてみました。

レビューさせるDDL

CREATE TABLE users (id int, user_name TEXT, create datetime);
CREATE TABLE user_items (id int, user_id VARCHAR(10), itemName TEXT, status VARCHAR(250), created datetime);

以下のような問題点を意図的に仕込みました。はたして、Gemini Code Assist はうまく指摘してくれるのでしょうか？

Primary Key が指定されていない
user_name の NOT NULL の指定漏れ
予約語 create が使用されてしまっている
users の id と user_items の user_id の型の不一致
users の create と user_items の created の表記揺れ
命名規則が CamelCase と SnakeCase の混在
不必要に大きな型 (user_name, status）

Gemini Code Assist を Github にインストール

developers.google.com

何も指示を与えない状態

とりあえず、何も指示をあたえず、デフォルトの状態でレビューさせてみます。 PRを作ると自動的に Gemini Code Assist がレビューを開始し、コメントをつけてくれます。１分程度で、結果が返ってきました。

https://github.com/samitani/DDLreview/pull/1

結果は以下でした。このリポジトリはDDLしかありません。情報が限られた中でのレビューということを考えると、かなり良い感じだと感じました。正直、この状態でも十分満足です。

✅ Primary Key が指定されていない
❌ user_name の NOT NULL の指定漏れ
✅ 予約語 create が使用されてしまっている
✅ users の id と user_items の user_id の型の不一致
❌ users の create と user_items の created の表記揺れ
✅ 命名規則が CamelCase と SnakeCase の混在
❌ 不必要に大きな型 (user_name, status）

それ以外にも、外部キー制約が必要な点が指摘されてます。

型が妥当かどうかは、ドメイン知識がないと判断が難しいのでしょう。アプリケーションのコードが一緒にコミットされてれば、検知してくれるかもしれません。

指示を与えてあらためてレビューさせる

.gemini/styleguide.md に指示を記述できます。適当に指示を追加してレビューさせてみましょう。

% cat .gemini/styleguide.md
日本語で回答してください。

# DDL をレビューするときのポイント

* 外部キー制約は任意とします。ただし、既存のテーブルで外部キー制約をすでに利用している場合は、常に外部キー制約を利用するようにしてください。
* カラム名の表記ゆれがないか確認してください。
* TEXT型が利用されている場合、VARCHAR型を検討してください。
* フラグやステータスといった値のバリエーションが固定されているカラムにはENUM型を検討してください。

https://github.com/samitani/DDLreview/pull/2

✅ Primary Key が指定されていない
❌ user_name の NOT NULL の指定漏れ
✅ 予約語 create が使用されてしまっている
✅ users の id と user_items の user_id の型の不一致
❌ users の create と user_items の created の表記揺れ
✅ 命名規則が CamelCase と SnakeCase の混在
✅不必要に大きな型 (user_name, status）

7 の型については指摘が入るようになりました。 5 の表記ゆれは今回もスルーされました。もうちょっと詳しく指示しないとダメかもしれません。

初期状態では外部キー制約を This is crucial と強く利用を勧めてきてましたが、指示を考慮して、今回はマイルドな指摘へと変化してます。

データ型を揃えることで、データ整合性を保つための外部キー制約 (FOREIGN KEY (user_id) REFERENCES users(id)) の追加も可能になります。

指示を改良してリトライ

表記ゆれを見逃さないように「似たカラム名がある場合、表記がゆれていないか確認してください」と怪しいケースを積極的にひろうように指示してみます。また、外部キーを任意としたので、代わりにインデックスの有無を確認するよう指示を足しました。

% git diff
diff --git a/.gemini/styleguide.md b/.gemini/styleguide.md
index c110d42..9038135 100644
--- a/.gemini/styleguide.md
+++ b/.gemini/styleguide.md
@@ -3,6 +3,7 @@
 # DDL をレビューするときのポイント

 * 外部キー制約は任意とします。ただし、既存のテーブルで外部キー制約をすでに利用している場合は、常に外部キー制約を利用するようにしてください。
-* カラム名の表記ゆれがないか確認してください。
+* キーとなるカラムにインデックスが追加されているか確認してください。
+* 似たカラム名がある場合、表記がゆれていないか確認してください。
 * TEXT型が利用されている場合、VARCHAR型を検討してください。
 * フラグやステータスといった値のバリエーションが固定されているカラムにはENUM型を検討してください。

https://github.com/samitani/DDLreview/pull/3

今回は表記ゆれもバッチリ検知してくれました 👏

中 (Medium): created カラム名も users テーブルと合わせて created_at に統一すると、スキーマ全体の一貫性が高まります。

高 (High): 外部キー候補である user_id カラムにインデックスがありません。検索パフォーマンス向上のため、インデックスの追加を強く推奨します。1

Gemini Code Assist すばらしい。

mita2 database life

主にMySQLに関するメモです