AIプログラミングは確かに便利なのですが、色々な振り回され方をします。特に一時的な処置をしたときに、その処置固有の問題について、恒久的な対策をしようとして、それが余計な処理になっている、というパターンがあるようです。今回そのパターンがありました。
自分用のWebアプリで、Linux版のデータの置き場所が想定と違うことがわかったので、変更するように指示しました。これはデータパスが変わるだけのシンプルなものです。人間がやると忘れ物が発生しがちですが、ここらへんは割とAI得意なので、特に問題はないだろうと思いました、が、その際、AIは気をきかせて既存データについても移行したりなんだりと始めたのですね。
まぁ既存データの移行も、別に僕がcpなりrsyncなりするのをやってくれただけなので、まぁ気を利かせてくれたならよろしい、と思ったのですが、なんかついでに、Web UIからのアップデート機能にも手を入れていたようなのです。
このアプリはアップデートを検知をしたらWeb UIからアップデートをかけられる機能があるのですが、どうもデータを移行している最中にアップデートが走るとバグると考えた、ようです。で、アップデート時にプロセス終了処理を明示的に入れよう的な、そういう余計な処理を入れたようなのですが、それによってアップデートしたらプロセスが落ちるというバグが入りました。そりゃそうだ。
このバグはアップデート時に発覚するものなので、その時はわからず、その次のアップデート時に「アップデートしたらアプリが落ちる」という事象が発生して発覚しました。勘弁してクレメンス。
まぁつまり時限爆弾を仕込んだ形です。これが配布アプリとか、まして仕事で納めたアプリで起きると困りもの。時限爆弾には色々なパターンがあるわけですが、インストール周りはやはり鬼門ですね。これはちょっと精査するのしんどいなぁ。特にローカルはクラウドよりも考えるところが増えるので、仕事では安全面に倒して自動でアプデみたいなことはやめておいたほうがいいかな。配布アプリはやりますが( ･`д･´)
時限爆弾といえば、データが積み重なっていくとデータベースのパフォーマンスが突然猛烈に劣化するなどもあります。DB設計については、納めるものならちゃんと見ておくべきでしょうね。
まぁ今回直接の原因となったのは、一発ものの処理があったことでしょう。一つだけではなく、ちょうどアップデート周りで、別の一時的な処理があって、それらが重なって、AIはありもしないリスクを過大に評価し、余計な処理を入れてしまった、といったところでしょう。なんとなく察せられました。
自分でやっていれば起きないことがAIに任せると起きるので、何をどこまで、どう任せるか、新たな考えどころが増えました。まぁそれでも、総合的に見ると信じられないほど開発速度ははやくなりましたが…。少なくとも、作りたいものを作るという観点では、良いものだと思います。
自分で書かないのは寂しさがある一方、どうせ組織にいても、もし上に行ければそうなるんですし。ざっくりの設計はわかっても、設計で縛れる領域は限られており、最後は詳細で、それがどうなっているかはわからない以上現場のエンジニアを信じるしかない…マネージャはこんな気持ちでいたのかもしれませんね。
コメント