ミニゲームをいくつか連続で追加した後、作業の流れが目に見えて悪くなり始めました。最も直接的なサインはトークンの消耗でした。新しいゲームを作る時に既存のゲームファイルをAIへの参考として渡す必要があるのですが、ゲームごとに構造が違って説明することが増えてしまい、作業を始めて2時間も経たないうちにコンテキスト上限に達することが増えました。同じ日にまた最初からセットアップし直すのが面倒で、一日にこなせる作業量が自然と減っていました。コード自体も問題でした。UIの構造や状態管理の方法がゲームごとにバラバラで、あるゲームで何かを直すと、他のゲームにも同様の修正を繰り返す必要がありました。このまま放置すれば、ゲームが増えるほど状況が悪化するのは明らかでした。
リファクタリングの前にテストコードを
リファクタリングしたいという気持ちはありましたが、いざ始めようとすると少し怖かったです。テストコードなしで構造を変えると、何かが静かに壊れることがあるんです。フロントエンドのコードはデプロイして実際に使ってみないとわからないバグが多く、バックエンドよりずっと不安です。そこで順序を変えました。まずAIに現在のコードに対するテストコードを書いてもらうことにしました。ゲームデータの構造が正しいか、必須フィールドが抜けていないか、多言語翻訳がすべて存在するかといった項目を自動で検証できるようにしました。テストが整った状態でコードを触ることで、何かが壊れた時にすぐに気づけるからです。
サーバー開発のように共通部分を先に洗い出した
テストの準備ができたところで、本格的なリファクタリングに入りました。アプローチは普段のバックエンド開発と似ていました。サーバーコードを書く時に共通ロジックをサービスレイヤーに切り出すように、ここでも「ゲーム間で重複しているものは何かを洗い出せ」とAIに指示しました。コード全体をスキャンして共通パターンを整理する作業から始めさせたんです。把握した内容をもとに、3つの方向で分離を進めました。1つ目はUIコンポーネントの統一です。ゲームごとにバラバラに実装されていたリザルトカードとランキングダッシュボードを共通コンポーネントとして切り出しました。2つ目は共通機能をフックに分離する作業でした。複数のゲームに散らばっていたゲーム中のサウンド処理コードを、単一のフックにまとめました。3つ目はファイル内のUIロジックとビジネスロジックの分離です。1つのファイルに画面描画コードとゲーム進行ロジックが混在していたケースを整理しました。
直したらテスト、直したらテスト
作業自体は単純なサイクルの繰り返しでした。AIにファイルを修正させて、全テストを回して、失敗したら原因を突き止めてまた修正する、というパターンを繰り返し続けました。辛かったのは、AIが先ほど指示した内容をなかなか実行しないことがあるという点でした。例えば「リザルトカードは必ず共通コンポーネントを使え」とすでに言ったのに、次のファイルを修正するときにこっそり昔の方法に戻ることがありました。ファイルが多いのでAIが前の指示を忘れてしまうのか、それとも内部的に何か優先順位の処理が変わるのかはわかりませんが、同じことを何度も繰り返し言わなければならない場面がかなりありました。
コードが20%減り、作業時間が1時間増えた
結果は期待していた以上でした。ファイル一つひとつのサイズが目に見えて縮小し、コード全体の量が約20%減りました。AIにファイルを参照させる際に不要な内容が多く省かれてトークン消費も減り、1セッションで作業できる時間が2時間から3時間程度に延びました。小さいことのように思えますが、体感の差は結構ありました。1日2回セットアップしなおす必要があったのが1回で済むようになるからです。AIへのガイドはリファクタリング前から運用していたのですが、今回リファクタリング後の構造の説明と、どのコンポーネントをいつ使うべきかという内容を新たに追加したことが効果を発揮しました。以前よりも全体的に統一感のある結果が出るようになり、修正依頼を送る頻度も減りました。
最初から大きな絵を描いていたら？
リファクタリングを終えて思ったのは、それでもこのタイミングでやったのは遅くなかったということでした。もちろん最初から共通コンポーネントとフックの構造を決めてから始めていれば、この時間を節約できたでしょう。でも正直、それは作ってみる前にはわかりにくいことです。どのパターンが共通で使われることになるか、どの部分が複雑になるかは、実際にゲームをいくつか作ってみて初めて見えてきました。最初から完璧な構造を設計しようとしていたら、実際には使いものにならない抽象化をたくさん作って、スタートが遅れた可能性が大きいです。
サービスというものはもともとそういうものだと思います。作りながら足りない部分を発見して、発見したら直して、直したらまた別のものが見えてくる。最初から完璧な設計図を描いてから始める人はほとんどいないでしょうし、それが常に正しいとも思いません。今回のリファクタリングから得た教訓があるとすれば、あまり長く溜め込まないうちに整理する時間を作る方がいい、ということくらいです。技術的負債は早く返すほど利子が少なくて済みますから。