バイブコーディングで破綻したらどうなるかなぁという記事を先日書いたばかりなのですが、なんか自分用アプリで早速破綻？しました。
データベース不整合
まぁ破綻というほどではないのですが、データベースで仕様上あってはならない不整合が生じた形ですね。具体的には、10の要素のうち1つのみenabledでほかはdisabledになる仕様のものがありましたが、最近追加した機能の利用により、意図せずして複数のenabledが生じる状態になりました。
そもそものデータベース設計に問題があるような気はしつつ、とりあえず修正し、そのうえでそもそもコードの行数が大きすぎないだろうか、とAIに聞いたところ例によって「まったくそのとおりです。リファクタリングが必要です」などと供述し…。
まぁこんな状態でした。
oh...。1000行以上が複数、最大で3000行近くのものもあり、といったところですね。さらに聞いてみるともっとも肥大化したdb.tsは15のドメインが単一ファイルに含まれているとのことで、どうしてこんなになるまで放っておいたんだみたいな状態でした。
ということで大規模なリファクタリング計画が実施されます。その計画自体はAIにさせましたが、十回以上に分割して、都度挙動を確認しながらやることになりました。修正自体はAIがやったとはいえ、確認はありますし、またけっこうな時間かかりましたね。
そもそも設計がおかしい
リファクタリングをした後に、そもそも論としてデータベース設計がおかしいよなぁということで、見直しました。状態は10のレコードがあって、それぞれstatusとしてenabled/disabledのboolをもち、1つだけenabledになる、という奇妙なものでした。この排他制御はアプリケーション側でやらざるを得ず、データベース上は不整合が生じうる状態です。
なのでこれは設計を変更し、一つのレコードのIDをactiveとして指定するようにしました。これによって、データベース上も不整合は生じなくなります。
最初からそうしとけばいいじゃないかという話なんですが、これもまた歴史的経緯によります。このアプリケーションは大昔自分がCLIで手作りしていたものがベースになっており、当時データはJSONファイルを扱うだけの簡易的なもので、IDの概念もリレーショナルの概念もありませんでした。
で、AIのおかげでGUIにできるし、DBもSQLiteにしたほうがいいぞなということで、いつだったか移行したんですけれど、その時に従前の仕様もかなり引きずられることになりました。正直この設計はよろしくない、とは思っていたのですけれど、なんか動いているんでまぁいいかと放置していました。
で、バグが生まれたってわけ。
それが僕には面倒くさかったから
まぁ、マイグレーションの時点で以前の設計はとりあえず残しておくのはいいと思うんですよ。まぁでも、おかしいよなと思った時点でさっさと手を付けるべきではありました。ただ設計変更ってどうしても考えてプロンプト打たないといけないので、結局面倒くさいんですよね…で、その結果もっと面倒くさいことになるといういつものあれ。
なので、バイブコーディングでDB不整合が生じたというより、人間がサボったので不整合が生じたというほうがいいのかもしれないんですが、しかし、移行などに伴って、以前の設計が現在適切ではないにも関わらず残ってしまう、はAIプログラミング時代において、気付ける人が限られるという点でけっこう深刻なんじゃないでしょうか、と強引にまとめて終わり。
<関連記事>
コメント